On 15.02.2012 20:15, Grozdan wrote:
> 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
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
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.
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.