On 15.02.2012 20:15, Grozdan wrote: > Hi, > > I just finished watching the excellent speech of Dave Chinner at > linux.conf.au and I must say I'm impressed by the recent improvements > to XFS. Towards the end of the talk, Dave talked about upcoming > improvements on Metadata reliability and other features. What I'm > wondering about is if there are any plans in making XFS transactional > (fully atomic) like it is the case with recent NTFS versions on > Windows Vista and higher? You could argue if it is NTFS doing the work at all. I glanced over a document describing it, and as far as i remember the KTM-Component does all the work and stores the changes into a specialized database. So effectivly you have a shim at the VFS-Layer that lets "others" see the old data while your application can see the new data and when you "commit", all the filesystem changes stored in the database are applied to the filesystem. As far as i unterstand it you wouldn't necessarily need support for that in the filesystem itself, you could do it at the VFS level. So one of the union/layered-"things" should be able to do that. IOW, store all the changes necessary and "replay" the changes to the actual filesystem when doing the commit. (Or the opposite, depending if you expect a commit or rollback as the default operation at transaction end.) Or BTRFS should be able to do that, when they implement snapshot at directory-level (AFAIR BTRFS currently supports snapshots at subvolume level, so if you use a subvolume you could already to that). You would snapshot the dir, do your work in the snapshot and switch the original dir with the snapshot on commit. Altough i don't know if you can switch a mounted subvolume, or if it has to be umounted first. Having to do a umount might be problematic, depending on use-case. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
