Created attachment 22143 [details] debug messages & oops. Running a test like this on 2.6.30-6.fc12 : #!/bin/bash mkfs.ext3 /dev/ram0 i=0 while (true); do i=`expr $i + 1` echo ------------------------------------------------------------- echo Cycle $i date echo Mounting sleep 1 mount -t ext3 /dev/ram0 /mnt/test || exit 1 echo Removing old fsstress data rm -rf /mnt/test/work mkdir /mnt/test/work || exit 1 echo Starting fsstress fsstress -d /mnt/test/work -p 3 -n 100000000 & echo Sleeping 30 seconds sleep 30 echo Stopping fsstress while (ps -e | grep fsstress);do pkill fsstress sleep 1 done echo Unmounting umount /mnt/test || exit 1 echo Checking sleep 1 e2fsck -fvp /dev/ram0 || exit 1 done I get an assertion failure on the unmount, see attachment. This testcase was originally reported at http://lkml.org/lkml/2008/11/14/121, though the end result was different, in that case corruption was found.
More likely to be a ramdisk bug. <checks> yup, according to Adrian's report, it happened after the introduction of brd. <marks as regression, assigns to Nick> hm, we don't have a category for ramdisk. I'll make it IO/Storage, Block layer.
Hm, ok. FWIW, running the same test w/ xfs found no errors, and xfs generally is quite good at letting you know if something got corrupted. *shrug* note that Adrian reported a different problem than I'm seeing now ...
It's a genuine ext3/4 bug appearing when allocation of block for a long symlink fails and I'm the one who wrote it :(. Anyway, attached patch should fix it.
Created attachment 22356 [details] Fix truncation of a long symlink after we failed to allocate a block for it
Eric, can you test the patch? It fixes the issue for me...
Sure thing, thanks Jan! This bug had dropped off my radar TBH ...
The patch worked for me and is already upstream... I'm closing this as fixed. Please reopen if you see the bug again. Thanks.