On Thu, 20 May 1999 00:42:41 -0400, "Kevin M. Bealer"
<kbealier@stny.lrun.com> said:
> We see an archetectural problem (FSCK takes to long to run), and
> are considering fixing it by making really big blocks. Now, I
> know there are other advantages, but every time the block size
> doubles, the fragmentation loss doubles. If we could stand the
> complexity, a buddy system for pieces over a small limit and under
> page-size might work, but I think we are fixing the wrong thing.
When you are dealing with large amounts of data, dealing with it in big
chunks is _always_ more efficient. Given the current on-disk layout,
that translates to large blocks. (Of course, with an extent-based
system we can deal with larger chunks of data while still maintaining a
fine grained allocation unit.)
> We need to fix the FSCK problem -
> My choice for the wishlist - filesystems that aren't modified after
> a certain amount of time, could by synced (sort of like a disk going
> to sleep), marked clean, and essentially remounted read-only,
Sun presented a neat paper on something like this at last Usenix, in
which they showed you could maintain information about which parts of
the filesystem were active and which idle, to narrow down the amount you
need to fsck. They were cutting fsck time by a factor of 4 or so on
average, if I remember correctly.
> 2. atimes would need to be dealt with. If atimes are enabled, we would
> want to have three states - clean, clean-except-atimes, and dirty.
> You don't need to sync if the atimes are the only dirty piece,
> because you can't fix them and it won't hurt if they are not
> fixed.
I've already implemented this for a different reason: it turns out that
we need it for fdatasync(), which flushes all file updates to disk
except for mtime and atime updates. In cases where you are updating
existing file data, fdatasync() eliminates an unnecessary seek to the
head of the file.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/