The series include the truncate_mutex to read write semaphore conversion. I am
marking below some of the test results.
For O_DIRECT workloads we won't see the contention on truncate mutex because we
are
doing a get_block under inode-i_mutex.
For FIBMAP we won't see contention because the
When doing a migrate from ext3 to ext4 inode we need to make sure the test
for inode type and walking inode data happens inside lock. To make this
happen move truncate_mutex early before checking the i_flags.
This actually should enable us to remove the verify_chain().
Signed-off-by: Aneesh
On Dec 13, 2007 20:36 -0600, Jose R. Santos wrote:
... if the value in the super block is corrupted and
does not represent the actual flexbg size, the inode allocation will
behave in weird unexpected ways. Just as we check that the bitmaps are
within the block group range (when not using
I have a hand-crafted bad filesystem image which has corruption:
[EMAIL PROTECTED] ~]# ls mnt/dir
file1 file2 file3 file4 file5
[EMAIL PROTECTED] ~]# ls mnt/dir/file4
ls: cannot access mnt/dir/file4: No such file or directory
[EMAIL PROTECTED] ~]# ls -l mnt/dir
ls: cannot access
I have a hand-crafted bad filesystem image which has corruption:
[EMAIL PROTECTED] ~]# ls mnt/dir
file1 file2 file3 file4 file5
[EMAIL PROTECTED] ~]# ls mnt/dir/file4
ls: cannot access mnt/dir/file4: No such file or directory
[EMAIL PROTECTED] ~]# ls -l mnt/dir
ls: cannot access
ext4 needs to deal with 2 different max file offsets for block- and
extent-allocated file formats, whereas the s_maxbytes scheme can only deal
with one. So, for block-allocated files, we must catch and fix up
too-large offsets from within the filesystem.
Having iov_shorten exported allows such
On Fri, 14 Dec 2007 10:01:06 -0700
Andreas Dilger [EMAIL PROTECTED] wrote:
Well, I can imagine in some cases that the flexbg will not be completely
contiguous on disk (e.g. after a filesystem resize, if there are bad
blocks, etc). As long as the group descriptors themselves are correct
(i.e.
