diff options
author | Tao Ma <tao.ma@oracle.com> | 2010-05-13 22:49:05 +0800 |
---|---|---|
committer | Joel Becker <joel.becker@oracle.com> | 2010-05-18 16:41:39 -0700 |
commit | 5f5261acb059f43c7fb9a2fac9d32c6ef4df2ed5 (patch) | |
tree | c4f7e8f4b774ff3bb7b0e60f4bb956729e51d5b6 /fs/ocfs2/suballoc.c | |
parent | d9ef75221a6247b758e1d7e18edb661996e4b7cf (diff) | |
download | linux-stable-5f5261acb059f43c7fb9a2fac9d32c6ef4df2ed5.tar.gz linux-stable-5f5261acb059f43c7fb9a2fac9d32c6ef4df2ed5.tar.bz2 linux-stable-5f5261acb059f43c7fb9a2fac9d32c6ef4df2ed5.zip |
ocfs2: Don't retry xattr set in case value extension fails.
In normal xattr set, the set sequence is inode, xattr block
and finally xattr bucket if we meet with a ENOSPC. But there
is a corner case.
So consider we will set a xattr whose value will be stored in
a cluster, and there is no xattr block by now. So we will
reserve 1 xattr block and 1 cluster for setting it. Now if we
fail in value extension(in case the volume is almost full and
we can't allocate the cluster because the check in
ocfs2_test_bg_bit_allocatable), ENOSPC will be returned. So
we will try to create a bucket(this time there is a chance that
the reserved cluster will be used), and when we try value extension
again, kernel bug happens. We did meet with it. Check the bug below.
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1251
This patch just try to avoid this by adding a set_abort in
ocfs2_xattr_set_ctxt, so in case ENOSPC happens in value extension,
we will check whether it is caused by the real ENOSPC or just the
full of inode or xattr block. If it is the first case, we set set_abort
so that we don't try any further. we are safe to exit directly here
ince it is really ENOSPC.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Diffstat (limited to 'fs/ocfs2/suballoc.c')
0 files changed, 0 insertions, 0 deletions