SODA Noriyuki <soda@sra.co.jp> writes:
> NFS server:
> OS version: Fedora Core 3 Linux
> "async" is specified in /etc/exports, thus the server violates
> the NFS protocol, and replys to requests before it stores
> changes to its disk.
The reason the protocol is speced the way it is is because it's the only way
to gaurantee the semantics match the traditional unix semantics of a local
filesystem.
That said I would have expected a good NFS server to still live up to
everything important as long as the server doesn't actually crash or get shut
down at any point.
I certainly would have expected tmpfs to live up to the traditional unix
filesystem semantics.
> *** 35,37 ****
> --- 35,38 ----
> NOTICE: drop cascades to table testschema.foo
> -- Should succeed
> DROP TABLESPACE testspace;
> + ERROR: tablespace "testspace" is not empty
This one looks like the unlink is returning before it completes and then
subsequent operations (perhaps only if they come from other processes?) are
allowed to see the old filesystem state. That really ought not every happen
even with async and certainly not in tmpfs.
This might bear some further testing. Can you send the exact commands you used
to set up the tmpfs filesystem? Also, it might be worth checking if Fedora
Core 3 has any relevant known bugs.
> ======================================================================
>
> *** ./expected/sanity_check.out Fri Sep 9 05:07:42 2005
> --- ./results/sanity_check.out Fri May 19 16:31:37 2006
> ***************
> *** 17,22 ****
> --- 17,24 ----
> circle_tbl | t
> fast_emp4000 | t
> func_index_heap | t
> + gcircle_tbl | t
> + gpolygon_tbl | t
> hash_f8_heap | t
> hash_i4_heap | t
> hash_name_heap | t
This seems pretty mystifying. Perhaps it's leftover stuff from the tablespace
that failed to get dropped?
--
greg