|
Benifit:
1. internal checkpoints on the fly
2. automatic recovery points on crash
3. checkpoints are internally consistent as a filesystem (no fsck)
4. good for realtime data storage (sequential allocation/writing, contiguous storage)
Disadvantages:
1. You cannot use all of the space (disk full) in a log structured filesystem without a deadlock. (they didn't address this at all)
2. Not suitable for small filesystems (and I think a 40GB filesystem is small, and they
didn't address this at all)
3. requires separate garbage collection.
The big problem ALL of the large filesystems ignore is how to backup the beast.
To rebuild a large filesystem from archives takes days to weeks (up to a month for
a 20TB filesystem 75% full, 3-5 days using proprietary storage applications.)
Such long rebuild times is acceptable, if you can be down that long... But I know of
no such facility that can be down that way.
Another problem (slightly addressed by GFS and Lustre) is the need for performance.
The filesystem really really need to allow distributed access (read/write), as well as
allow distributed storage. The JFS under AIX is both distributed data, and
distributed access - I don't know about the Linux version,but I don't think it is either.
One of the things I've worked on was an engineering study for an archive filesystem,
which totally separates meta-data (directories, inodes) from the file data storage. I
based it partially on MySQLfs and a lot of changes aimed at automatic recovery,
reduced backup time (only the meta-data database(s) need be backed up), multiple
read/write (a read mostly database, with updates controlled by storage servers).
Not very fast though. There is a real need for data caching - which introduces a
lot lock issues...
|
Linear Mode
