Re: ext3-2.4-0.9.4

Matthias Andree (matthias.andree@stud.uni-dortmund.de)
Thu, 2 Aug 2001 11:03:41 +0200


On Wed, 01 Aug 2001, Stephen Tweedie wrote:

> > Chase up to the root manually, because Linux' ext2 violates SUS v2
> > fsync() (which requires meta data synched BTW)
>
> Please quote chapter and verse --- my reading of SUS shows no such
> requirement.
>
> fsync is required to force "all currently queued I/O operations
> associated with the file indicated by file descriptor fildes to the
> synchronised I/O completion state." But as you should know, directory
> entries and files are NOT the same thing in Unix/SUS.

Read on: "All I/O operations are completed as defined for synchronised
I/O _file_ integrity completion.". To show what that means, see the
glossary.

http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html#tag_004_000_291

"synchronised I/O data integrity completion

[...]

* For write, when the operation has been completed or diagnosed if
unsuccessful. The write is complete only when the data specified in
the write request is successfully transferred and all file system
information required to retrieve the data is successfully transferred.

File attributes that are not necessary for data retrieval (access
time, modification time, status change time) need not be successfully
transferred prior to returning to the calling process.

synchronised I/O file integrity completion

Identical to a synchronised I/O data integrity completion with the
addition that all file attributes relative to the I/O operation
(including access time, modification time, status change time) will be
successfully transferred prior to returning to the calling process."

As I understand it, the directory entry's st_ino is a file attribute
necessary for data retrieval and also contains the m/a/ctime, so it must
be flushed to disk on fsync() as well.

> There can be many ways of reaching that file in the directory
> hierarchy, or there can be none, but fsync() doesn't talk at all about
> the status of those dirents after the sync.

Well, if there's not a single dirent, you cannot retrieve the data, so
I'd assume at least one dirent needs to be flushed as well. If there's a
simple way to get unflushed dentries to disk (hard links included),
flush them. Not sure about symlinks, but since they don't share the
inode number, that might be rather difficult for the kernel (I didn't
check):

touch 1 ; ln 1 2 ; ln -s 1 3 ; ls -li

303464 -rw-r--r-- 2 emma users 0 Aug 2 10:56 1
303464 -rw-r--r-- 2 emma users 0 Aug 2 10:56 2
303466 lrwxrwxrwx 1 emma users 1 Aug 2 10:56 3 -> 1

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/