xfs
[Top] [All Lists]

Re: Transactional XFS?

To: Grozdan <neutrino8@xxxxxxxxx>
Subject: Re: Transactional XFS?
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Thu, 16 Feb 2012 13:01:42 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <CAFLt3phWcaQ4K3OPSVUkyN0BXqh+jQgQbeA59Oav23aOPLYMYw@xxxxxxxxxxxxxx>
References: <CAFLt3phWcaQ4K3OPSVUkyN0BXqh+jQgQbeA59Oav23aOPLYMYw@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.

<Prev in Thread] Current Thread [Next in Thread>