Hi Allison,
I found quite disturbing problem when testing loop discard support on
file systems where PAGE_SIZE > blocksize. The result is that the file
system image is completely destroyed, but the underlying file system
seems ok. I have seen this messages in the logs:
EXT4-fs error (device sdb): ext4_ext_search_left:1221: inode #12: comm
flush-8:16: ix (2248761) != EXT_FIRST_INDEX (0) (depth 1)!
EXT4-fs (sdb): delayed block allocation failed for inode 12 at logical
offset 2258177 with max blocks 64 with error -5
EXT4-fs (sdb): This should not happen!! Data will be lost
and
EXT4-fs error (device sdd2): ext4_ext_get_blocks: inode #12: (comm
loop0) bad extent address iblock: 34479, depth: 3 pblock 0
Steps to reproduce
mkfs.ext4 -b1024 /dev/sdb
mount /dev/sdb /mnt/test2
dd if=/dev/zero of=/mnt/test2/file bs=1M count=4096
losetup /dev/loop0 /mnt/test2/file
cd xfstests
export TEST_DIR=/mnt/test
export TEST_DEV=/dev/sda
export SCRATCH_DEV=/dev/loop0
export SCRATCH_MNT=/mnt/test1
export MKFS_OPTIONS="-F -b1024"
export MOUNT_OPTIONS="-o discard"
export FSTYP="ext4"
while ./check 251; do echo "OK"; done
..and just wait and watch the logs.
Do you have any idea what might be the problem ?
Thanks!
-Lukas
On 02/10/2012 12:10 PM, Lukas Czerner wrote:
> Hi Allison,
>
> I found quite disturbing problem when testing loop discard support on
> file systems where PAGE_SIZE> blocksize. The result is that the file
> system image is completely destroyed, but the underlying file system
> seems ok. I have seen this messages in the logs:
>
> EXT4-fs error (device sdb): ext4_ext_search_left:1221: inode #12: comm
> flush-8:16: ix (2248761) != EXT_FIRST_INDEX (0) (depth 1)!
> EXT4-fs (sdb): delayed block allocation failed for inode 12 at logical
> offset 2258177 with max blocks 64 with error -5
> EXT4-fs (sdb): This should not happen!! Data will be lost
>
> and
>
> EXT4-fs error (device sdd2): ext4_ext_get_blocks: inode #12: (comm
> loop0) bad extent address iblock: 34479, depth: 3 pblock 0
>
> Steps to reproduce
>
> mkfs.ext4 -b1024 /dev/sdb
> mount /dev/sdb /mnt/test2
> dd if=/dev/zero of=/mnt/test2/file bs=1M count=4096
> losetup /dev/loop0 /mnt/test2/file
>
> cd xfstests
>
> export TEST_DIR=/mnt/test
> export TEST_DEV=/dev/sda
> export SCRATCH_DEV=/dev/loop0
> export SCRATCH_MNT=/mnt/test1
> export MKFS_OPTIONS="-F -b1024"
> export MOUNT_OPTIONS="-o discard"
> export FSTYP="ext4"
>
> while ./check 251; do echo "OK"; done
>
> ..and just wait and watch the logs.
>
> Do you have any idea what might be the problem ?
>
> Thanks!
> -Lukas
>
Hi Lukas,
Im having some trouble getting the bug to reproduce for me. I have the
dm-crypt module, but when I get to the test loop, i get "mount: unknown
filesystem type 'crypto_LUKS'". Is there something else I need to do or
install? With out being able to dig into it, I cant think of why it
would do that, I have not seen it produce that error before. :( Thx!
Allison Henderson
On Sun, 12 Feb 2012, Allison Henderson wrote:
> On 02/10/2012 12:10 PM, Lukas Czerner wrote:
> > Hi Allison,
> >
> > I found quite disturbing problem when testing loop discard support on
> > file systems where PAGE_SIZE> blocksize. The result is that the file
> > system image is completely destroyed, but the underlying file system
> > seems ok. I have seen this messages in the logs:
> >
> > EXT4-fs error (device sdb): ext4_ext_search_left:1221: inode #12: comm
> > flush-8:16: ix (2248761) != EXT_FIRST_INDEX (0) (depth 1)!
> > EXT4-fs (sdb): delayed block allocation failed for inode 12 at logical
> > offset 2258177 with max blocks 64 with error -5
> > EXT4-fs (sdb): This should not happen!! Data will be lost
> >
> > and
> >
> > EXT4-fs error (device sdd2): ext4_ext_get_blocks: inode #12: (comm
> > loop0) bad extent address iblock: 34479, depth: 3 pblock 0
> >
> > Steps to reproduce
> >
> > mkfs.ext4 -b1024 /dev/sdb
> > mount /dev/sdb /mnt/test2
> > dd if=/dev/zero of=/mnt/test2/file bs=1M count=4096
> > losetup /dev/loop0 /mnt/test2/file
> >
> > cd xfstests
> >
> > export TEST_DIR=/mnt/test
> > export TEST_DEV=/dev/sda
> > export SCRATCH_DEV=/dev/loop0
> > export SCRATCH_MNT=/mnt/test1
> > export MKFS_OPTIONS="-F -b1024"
> > export MOUNT_OPTIONS="-o discard"
> > export FSTYP="ext4"
> >
> > while ./check 251; do echo "OK"; done
> >
> > ..and just wait and watch the logs.
> >
> > Do you have any idea what might be the problem ?
> >
> > Thanks!
> > -Lukas
> >
>
> Hi Lukas,
>
> Im having some trouble getting the bug to reproduce for me. I have the
> dm-crypt module, but when I get to the test loop, i get "mount: unknown
> filesystem type 'crypto_LUKS'". Is there something else I need to do or
> install? With out being able to dig into it, I cant think of why it would do
> that, I have not seen it produce that error before. :( Thx!
>
> Allison Henderson
Hi Allison,
I do not understand it either, there is no dm-crypt involved in this
scenario. One think that comes to my mind is that TEST_DEV (in my case
/dev/sda) needs to contain valid file system, but that is just how
xfstests works. Please, let me know if you still have problems
reproducing it.
Thanks!
-Lukas
On 02/12/2012 03:31 AM, Lukas Czerner wrote:
> On Sun, 12 Feb 2012, Allison Henderson wrote:
>
>> On 02/10/2012 12:10 PM, Lukas Czerner wrote:
>>> Hi Allison,
>>>
>>> I found quite disturbing problem when testing loop discard support on
>>> file systems where PAGE_SIZE> blocksize. The result is that the file
>>> system image is completely destroyed, but the underlying file system
>>> seems ok. I have seen this messages in the logs:
>>>
>>> EXT4-fs error (device sdb): ext4_ext_search_left:1221: inode #12: comm
>>> flush-8:16: ix (2248761) != EXT_FIRST_INDEX (0) (depth 1)!
>>> EXT4-fs (sdb): delayed block allocation failed for inode 12 at logical
>>> offset 2258177 with max blocks 64 with error -5
>>> EXT4-fs (sdb): This should not happen!! Data will be lost
>>>
>>> and
>>>
>>> EXT4-fs error (device sdd2): ext4_ext_get_blocks: inode #12: (comm
>>> loop0) bad extent address iblock: 34479, depth: 3 pblock 0
>>>
>>> Steps to reproduce
>>>
>>> mkfs.ext4 -b1024 /dev/sdb
>>> mount /dev/sdb /mnt/test2
>>> dd if=/dev/zero of=/mnt/test2/file bs=1M count=4096
>>> losetup /dev/loop0 /mnt/test2/file
>>>
>>> cd xfstests
>>>
>>> export TEST_DIR=/mnt/test
>>> export TEST_DEV=/dev/sda
>>> export SCRATCH_DEV=/dev/loop0
>>> export SCRATCH_MNT=/mnt/test1
>>> export MKFS_OPTIONS="-F -b1024"
>>> export MOUNT_OPTIONS="-o discard"
>>> export FSTYP="ext4"
>>>
>>> while ./check 251; do echo "OK"; done
>>>
>>> ..and just wait and watch the logs.
>>>
>>> Do you have any idea what might be the problem ?
>>>
>>> Thanks!
>>> -Lukas
>>>
>>
>> Hi Lukas,
>>
>> Im having some trouble getting the bug to reproduce for me. I have the
>> dm-crypt module, but when I get to the test loop, i get "mount: unknown
>> filesystem type 'crypto_LUKS'". Is there something else I need to do or
>> install? With out being able to dig into it, I cant think of why it would do
>> that, I have not seen it produce that error before. :( Thx!
>>
>> Allison Henderson
>
> Hi Allison,
>
> I do not understand it either, there is no dm-crypt involved in this
> scenario. One think that comes to my mind is that TEST_DEV (in my case
> /dev/sda) needs to contain valid file system, but that is just how
> xfstests works. Please, let me know if you still have problems
> reproducing it.
>
> Thanks!
> -Lukas
>
Ok, I got it, it was my fault I had forgotten that I had used the
scratch partition for an encryption test a while back. Sorry! I am
getting a "[not run] FSTRIM is not supported" though, I think I need a
device that supports discard. I will poke around Monday and see if I
can borrow one from somebody.
Allison Henderson
On Sun, 12 Feb 2012, Allison Henderson wrote:
> On 02/12/2012 03:31 AM, Lukas Czerner wrote:
> > On Sun, 12 Feb 2012, Allison Henderson wrote:
> >
> > > On 02/10/2012 12:10 PM, Lukas Czerner wrote:
> > > > Hi Allison,
> > > >
> > > > I found quite disturbing problem when testing loop discard support on
> > > > file systems where PAGE_SIZE> blocksize. The result is that the file
> > > > system image is completely destroyed, but the underlying file system
> > > > seems ok. I have seen this messages in the logs:
> > > >
> > > > EXT4-fs error (device sdb): ext4_ext_search_left:1221: inode #12: comm
> > > > flush-8:16: ix (2248761) != EXT_FIRST_INDEX (0) (depth 1)!
> > > > EXT4-fs (sdb): delayed block allocation failed for inode 12 at logical
> > > > offset 2258177 with max blocks 64 with error -5
> > > > EXT4-fs (sdb): This should not happen!! Data will be lost
> > > >
> > > > and
> > > >
> > > > EXT4-fs error (device sdd2): ext4_ext_get_blocks: inode #12: (comm
> > > > loop0) bad extent address iblock: 34479, depth: 3 pblock 0
> > > >
> > > > Steps to reproduce
> > > >
> > > > mkfs.ext4 -b1024 /dev/sdb
> > > > mount /dev/sdb /mnt/test2
> > > > dd if=/dev/zero of=/mnt/test2/file bs=1M count=4096
> > > > losetup /dev/loop0 /mnt/test2/file
> > > >
> > > > cd xfstests
> > > >
> > > > export TEST_DIR=/mnt/test
> > > > export TEST_DEV=/dev/sda
> > > > export SCRATCH_DEV=/dev/loop0
> > > > export SCRATCH_MNT=/mnt/test1
> > > > export MKFS_OPTIONS="-F -b1024"
> > > > export MOUNT_OPTIONS="-o discard"
> > > > export FSTYP="ext4"
> > > >
> > > > while ./check 251; do echo "OK"; done
> > > >
> > > > ..and just wait and watch the logs.
> > > >
> > > > Do you have any idea what might be the problem ?
> > > >
> > > > Thanks!
> > > > -Lukas
> > > >
> > >
> > > Hi Lukas,
> > >
> > > Im having some trouble getting the bug to reproduce for me. I have the
> > > dm-crypt module, but when I get to the test loop, i get "mount: unknown
> > > filesystem type 'crypto_LUKS'". Is there something else I need to do or
> > > install? With out being able to dig into it, I cant think of why it would
> > > do
> > > that, I have not seen it produce that error before. :( Thx!
> > >
> > > Allison Henderson
> >
> > Hi Allison,
> >
> > I do not understand it either, there is no dm-crypt involved in this
> > scenario. One think that comes to my mind is that TEST_DEV (in my case
> > /dev/sda) needs to contain valid file system, but that is just how
> > xfstests works. Please, let me know if you still have problems
> > reproducing it.
> >
> > Thanks!
> > -Lukas
> >
> Ok, I got it, it was my fault I had forgotten that I had used the scratch
> partition for an encryption test a while back. Sorry! I am getting a "[not
> run] FSTRIM is not supported" though, I think I need a device that supports
> discard. I will poke around Monday and see if I can borrow one from somebody.
>
> Allison Henderson
Well, you'll have to try that on the recent upstream kernel, or at least
the one which has my loop discard support patch
dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef
so we convert the discard command in the loop driver into punch hole to
the backing file. But I have been able to reproduce it just with dd and
fallocate - just create a file with some extents and then puch a hole in
the size of the file and you'll get the error. I believe that there is
some kind of off-by-one error (probabaly blocks count vs. block
number:)). I have not had time to investigate this issue, but I'll look
into it soon.
Thanks!
-Lukas