Re: xattr atomicy

[Ben Myers <bpm@sgi.com>]

Hey Christoph,

On Fri, Dec 13, 2013 at 03:56:44AM -0800, Christoph Hellwig wrote:
> On the nfsv4 list it was recently discussed how atomic / transaction
> xattr updates are.  It turns out none of that seems documented on the
> syscall level, but for XFS we have an odd inconsistancy in that attr
> updates generally are atomic and logged, except when we go out to
> remote attributes in xfs_attr_rmtval_set, in which case attr updates
> are no logged, and we do synchronous writes instead.
> 
> Besides the weird semantic difference that is impossible to explain to
> users performance will also generally be bad with a synchronous buffer
> write.  Is there any good reason to not log the buffer for the remote
> attributes? Given that attribute are limited to 64kB it's not like
> the value is larger than large directory blocks that we already
> support.

Looks like it's just because we're concerned about the size of the transaction:

1221 STATIC int
1222 xfs_attr_node_addname(xfs_da_args_t *args)
1223 {
...
1359         /*
1360          * If there was an out-of-line value, allocate the blocks we
1361          * identified for its storage and copy the value.  This is done
1362          * after we create the attribute so that we don't overflow the
1363          * maximum size of a transaction and/or hit a deadlock.
1364          */
1365         if (args->rmtblkno > 0) {
1366                 error = xfs_attr_rmtval_set(args);
1367                 if (error)
1368                         return(error);
1369         }

I'm not clear on what the deadlock might have been.

-Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs