:Thanks. It seems to me that for a filesystem, a block (or a fragment) is
:the unit of I/O. Even if a single byte is modified, an entire block
:probably consisting of multiple sectors must be written back to the disk.
:As you said, there is no differnce whether we write this block one sector
:at a time or in a single transfer. If so, I wonder whether the atomicity
:of a sector I/O required by a directory file is necessary any more.
:
:-Zhihui
The directory blocking is there for a different reason. Atomicy does not
have much to do with it though perhaps it did at some point in the past.
The reason directory entries are not allowed to cross a 'block' boundry is
two fold:
* First, to properly support the use of a directory offsets for
seeking into directories when doing a complex directory scan.
Since userland can supply any offset, even a garbage offset,
the kernel code needs to be able to find a starting point from which
it can scan forward to locate the directory entry the user is
requesting and *be sure* that it is a legal entry.
The filesystem avoids having to scan from the very beginning of a
potentially huge directory by understanding that it can start at
the beginning of the directory block containing the offset.
* Second, to simplify the directory scanning code. The kernel maps
filesystem buffers into memory on a filesystem block-by-block basis.
The directory scanning code is greatly simplified by not allowing
directory entries to cross a block boundry.
There are also other issues involved relating to newer system calls
and even NFS that pretty much requires directory entries to not cross
block boundries, though in these cases the 'size' of the block is kinda
fuzzy. There are also legacy issues.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
