From: Matthias Schniedermeyer <ms@citd.de>
To: Grozdan <neutrino8@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Transactional XFS?
Date: Thu, 16 Feb 2012 13:01:42 +0100 [thread overview]
Message-ID: <20120216120142.GA18800@citd.de> (raw)
In-Reply-To: <CAFLt3phWcaQ4K3OPSVUkyN0BXqh+jQgQbeA59Oav23aOPLYMYw@mail.gmail.com>
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2012-02-16 12:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-15 19:15 Transactional XFS? Grozdan
2012-02-16 0:22 ` Dave Chinner
2012-02-16 1:01 ` Stewart Smith
2012-02-16 1:43 ` Dave Chinner
2012-02-16 5:38 ` Stewart Smith
2012-02-16 6:42 ` Dave Chinner
2012-02-17 4:40 ` Stewart Smith
2012-02-16 22:10 ` Peter Grandi
2012-02-16 12:01 ` Matthias Schniedermeyer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120216120142.GA18800@citd.de \
--to=ms@citd.de \
--cc=neutrino8@gmail.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox