Isnt it an extreme case of "badblock" ?
> filesystem. This would make a really big difference as far as
> performance on busy filesystems and prolonging the life of batteries in
> a laptop computer, since atime updates would rarely get flushed to disk.
Im poking at this at little in a variant form. The PC110 has a 4Mb
battery backed ram disk and a PCMCIA hard disk. What I want to do is
to use the ram disk as a write buffer to the physical media to lower
battery use.
> needs to be done periodically because (a) you want files that are
> written to be actually committed, and (b) disk blocks which are freed
> due to a file deletion or truncation can't be re-used until the commit
> happens.
You are assuming you are logging for the purpose of clean recovery from
all cases. The laptop case of logging for power management is a simpler
starting point as you dont care if you have to fsck the disk (and peek
into the log whats left of it anyway).
> As far as hashing or B-tree directory structures, and extent-based
> filesystems, those are things which are possible in the ext2 filesystem
> as well. There is an obvious design question about whether it's simpler
> to build these sorts of things in from scratch, or take an existing
> filesystem and add these features.
We have the libraries for B trees in the kernel hfs module, and they
are extremely clean and thus could be readily transported to ext2.
> esoteric features such as the log-structured filesystems and generalized
> volume management (beyond just RAID-oriented schemes), you might as well
> start from scratch. However, there's a cost-benefit tradeoff to these
I'd prefer to see volume management as a part of the RAID stuff, even down
to the idea that a disk is a sort of poor RAID0 array. This gives us benefits
we can apply to other file systems too later on
Alan