Recently filesystem activity besides ext4 in Linux kernel is Tux3. Which, in technicial, is really B-Tree extents based filesystem like ext4 or reiserfs. Despite of it not too complete and not stable now, Tux3 is journal fileystem with log and atomic commit. New atomic commit approch is to write metadata update to logical log (memory) and then data blocks to physical storage follow by commit block. Then update metadata (from logical to physical) afterwards, unlike NTFS and other journaled fileystem. Transaction on Tux3 are considered completed after log is written and will not replay any metadata but will load log in place every mount to check filesystem consistency. That simplify maintain data consistency when disk is hot remove and make sure log recovery code is well tested. Considered situation when atomic commit is not complete (data blocks not contains commit block), after mounted, log not need to replay because corrupted data is written somewhere not the same block as previously reside in.
Seems SSD and flash based disks really benefits from Tux3 implementation which not require much performance of contigous blocks or fragments data but reduce write levering that will turn disk in to short life.
0 Trackbacks