Whamcloud - gitweb
LU-5626 ldiskfs: update non-htree dotdot in rename 26/12926/2
authorPatrick Farrell <paf@cray.com>
Wed, 3 Dec 2014 23:26:59 +0000 (15:26 -0800)
committerOleg Drokin <oleg.drokin@intel.com>
Tue, 9 Dec 2014 00:41:09 +0000 (00:41 +0000)
commit76a7bae58006e4f6d1c13216df8cedda85e5e911
tree2dcaf89ad52b72ab48566f66617c07d600edbfe0
parent2976f91adb4d0362b7ebb54e9972156c438bcb73
LU-5626 ldiskfs: update non-htree dotdot in rename

In 2.4+, when renaming a directory, its old dotdot entry will
be removed firstly, then the new dotdot entry is inserted, and
ldiskfs tries to append FID-in-dirent to the new entry.
But the space for dotdot entry may not be enough to hold
the new dotdot with FID-in-dirent, such as an MDT device
restored from file-level backup, or a device upgraded from 1.8.

In that case, for non-HTree directories, the ".." entry
will be written in the next available space in the directory
block.  This is invalid, as the ".." entry must be the
second entry in the block.

The same bug was fixed for HTree directories in LU-2638.
As Fan Yong said then: we do not want to introduce
complex logic to handle directory data moving, instead, in
such case, ignore the FID-in-dirent for the new dotdot entry,
and just insert the new dotdot entry.

There is one known flaw: This patch, like the one for
LU-2638, skips the entire data section rather than just
the FID.  This could cause trouble if something else ever
uses this section with ".." entries.

This patch is back-ported from the following one:
Lustre-commit: 38ec486aeee20345a86dbbd2022d7976337c49b8
Lustre-change: http://review.whamcloud.com/11939

Signed-off-by: Patrick Farrell <paf@cray.com>
Change-Id: I509b960b111d12d6375c967163f50199cb8f76bf
Reviewed-on: http://review.whamcloud.com/12926
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Fan Yong <fan.yong@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
ldiskfs/kernel_patches/patches/rhel6.3/ext4_data_in_dirent.patch