So which, if I may ask, are the advantages of your design over sprite
lfs?
It is very different from LFS. LFS is log-filesystem, i.e. journal spans
the whole device. The problem with this design is that it's fast for write
(cool benchmark numbers) and slow in real-world workloads.
LFS places files according to time they were created, not according to
their directory.
If you have directory with some project where you have files that you
edited today, day ago, week ago, month ago etc., then any current
filesystem (even ext2) will try to place files near each other --- while
LFS will scatter the files over the whole partition according to time they
were written. --- I believe that this is the reason why log-structured
filesystems are not in wild use --- this is a case where optimizing for
benchmark kills real-world performance.
Darn, I was asking the wrong question again. Let me rephrase:
So which, if I may ask, are the advantages of your crash
count/transaction count design over the sprite lfs checkpoint design?
Allocation strategy is an interesting topic as well. Rosenblum and
Ousterhout were wrong in their base assumption that read performance
won't matter long-term, as caches are exponentially growing. It
turned out that storage size was growing just as fast and the ratio
remained roughly the same. But let us postpone that for a while.
Jörn
LFS fragments data by design ... it can't write to already allocated
space, so if you write to the middle of LFS directory, it will allocate
new block, new indirect pointers to that directory, new block in inode
table etc.
The same fragmentation with files (although with files it could be fixed
by not relying on consistecny of their content).
Mikulas
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
