Btrfs: fix hash overflow handling
authorChris Mason <chris.mason@fusionio.com>
Mon, 17 Dec 2012 19:26:57 +0000 (14:26 -0500)
committerChris Mason <chris.mason@fusionio.com>
Mon, 17 Dec 2012 19:48:21 +0000 (14:48 -0500)
commit9c52057c698fb96f8f07e7a4bcf4801a092bda89
tree5c26913c90c079ea1f8c287a925e2f7c0a3936fe
parentc64c2bd890df3b9a66c52c33df110777058c011e
Btrfs: fix hash overflow handling

The handling for directory crc hash overflows was fairly obscure,
split_leaf returns EOVERFLOW when we try to extend the item and that is
supposed to bubble up to userland.  For a while it did so, but along the
way we added better handling of errors and forced the FS readonly if we
hit IO errors during the directory insertion.

Along the way, we started testing only for EEXIST and the EOVERFLOW case
was dropped.  The end result is that we may force the FS readonly if we
catch a directory hash bucket overflow.

This fixes a few problem spots.  First I add tests for EOVERFLOW in the
places where we can safely just return the error up the chain.

btrfs_rename is harder though, because it tries to insert the new
directory item only after it has already unlinked anything the rename
was going to overwrite.  Rather than adding very complex logic, I added
a helper to test for the hash overflow case early while it is still safe
to bail out.

Snapshot and subvolume creation had a similar problem, so they are using
the new helper now too.

Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Reported-by: Pascal Junod <pascal@junod.info>
fs/btrfs/ctree.h
fs/btrfs/dir-item.c
fs/btrfs/inode.c
fs/btrfs/ioctl.c
fs/btrfs/transaction.c