xfs
[Top] [All Lists]

Re: xattr atomicy

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xattr atomicy
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 16 Dec 2013 07:19:00 -0800
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131213215117.GV10988@dastard>
References: <20131213115644.GA28551@xxxxxxxxxxxxx> <20131213215117.GV10988@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sat, Dec 14, 2013 at 08:51:17AM +1100, Dave Chinner wrote:
> Yes, but they are still atomic from a user and crash recovery
> point of view....

I can't see how we can guarantee an atomic update for them, both
in the case of an I/O error and an actual system crash.

> Well, I think it's a bit different to the directory block case - the
> directory blocks are filesystem metadata, while xattrs contain user
> data. Hence if we log user xattrs a user can consume all of the log
> bandwidth writing xattrs and degrade the metadata modification
> performance of the rest of the filesystem.

We're getting close to do that with namespace modifications with
all your scalability work :)

I think that's a point to consider, but not really black and white.  It
just makes it a bit easier to consume log bandwith, and increases the
need to have some form of per-user quotas for this sort of operations.

> So, IMO, the first question we need to answer is whether the current
> behaviour is actually a problem for anyone....

I've not heard of real life problems, but an interfaces that has very
nice behavior for the common case, but a much less optimal for a corner
cases is bound to cause trouble.

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