On Tue, Sep 11, 2012 at 11:31:23AM -0600, Wade Cline wrote:
> Hi,
>
> I was doing some fragmentation tests on preallocated extents on Josef's
> btrfs-next branch (commit 8fe3b6) with the O_DIRECT flag enabled and
> noticed some strange behavior. Writing to a preallocated extent
> currently triggers a WARN_ON on in the kernel, triggers a csum error for
> what appears to be each block, and causes the remaining preallocated
> (and not written-to) area to read 1's.
>
> The issue seems to have appeared in commit 8d37ef "Btrfs: improve fsync
> by filtering extents that we want" but the issues started earlier in
> 16ecb6 "Btrfs: turbo charge fsync". Prior to 16ecb6, direct I/O on
> preallocated extents was not generating false data, after 16ecb6 direct
> I/O was not writing -any- data, and after 8d37ef direct I/O was
> generating false data.
>
> The tests were done using a simple program I wrote (below) which
> preallocates a 128k file and performs a 4096-byte write.
>
> Steps to reproduce:
>
> mkfs.btrfs /dev/sdb
> mount -t btrfs /dev/sdb /mnt/btrfs
> cd /mnt/btrfs
> gcc -o main <../main.c>
> ./main single direct
> od -A x -t x2 testfile
>
> It seems that the issue in part occurs in unpin_extent_cache:
>
> WARN_ON(!em || em->start != start);
>
> printk() shows that the function expects the extent_map for the write
> performed but instead receives the extent_map for the entire
> preallocated extent. The extent_map is then marked as read:
>
> if (test_bit(EXTENT_FLAG_PREALLOC, &em->flags)) {
> prealloc = true;
> clear_bit(EXTENT_FLAG_PREALLOC, &em->flags);
> }
>
> which also causes fragmentation issues from further writes. I am not
> sure where the 1's are generated, though; using dd to check the on-disk
> contents shows that the data is uninitialized.
>
> I don't currently have a patch for this, but thought it was important
> enough to bring up. Below are the od output, the main.c code I used to
> produce this error, and the kernel message. Let me know if you have any
> questions.
Heh oops sorry about that, I know what's wrong and I thought about it when I was
writing these patches but then I never went back to check to make sure DIO did
the right thing. I will fix it up and run your test to make sure I got it
right. Thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
