Latest working kernel version: unknown Earliest failing kernel version: 2.6.28.2 Distribution: Hardware Environment: Software Environment: Explained kernel versions Descriptions: I used both Linux 2.6.28.2 and 2.6.29-rc2-git3 . With Linux2.6.28.2 , I used btrfs 0.17 provided by http://www.kernel.org/pub/linux/kernel/people/mason/btrfs/ Problem Description: btrfs is still a wreck Steps to reproduce: In introduction, please read my 'cat /proc/partitions' output: major minor #blocks name 3 0 58605120 hda 3 1 20024991 hda1 3 2 1959930 hda2 3 4 1 hda4 3 5 497983 hda5 3 6 8787523 hda6 3 7 26274276 hda7 3 8 1052226 hda8 254 0 1959930 dm-0 254 1 497983 dm-1 7 0 393216 loop0 I will use /dev/hda8 for BTRFS-related experiments. Beside creating a fresh-new btrfs filesystem and mounting is straightly, using the following commands: dd bs=1M if=/dev/zero of=/dev/hda8 mkfs.btrfs /dev/hda8 mount /dev/hda8 /mnt/hda8 I have 2 test usecases : - Usecase A: Extract linux-2.6.29-rc2 to /mnt/hda8 - Usecase B: Create an approx 400MB emty (zeroed-file) in the /mnt/hda8 directory Usecase A consists in: ( cd /mnt/hda8 && tar -xzf /home/testr/Custom_Builds/Pristine_Kernel/linux-2.6.29-rc2-git3.tar.gz ) Usecase B consists in: ( cd /mnt/hda8 && dd bs=1M count=400 if=/dev/zero of=./400MB.bin ) Reversed usecases would consist in : Usecase A' consists in: rm -vRf /mnt/hda8/linux-2.6.29-rc2-git3 Usecase B' consists in: rm -v /mnt/hda8/400MB.bin The problems I had to face were (Always from a scratch new btrfs-formatted /dev/hda8 filesystem): Going through usecase A, then through usecase B lead to a kernel Oops. --> Unable to unmount /mnt/hda8 either Going through usecase B, then through usecase A didn't show out a bug ; then, reverting uses case A by trying to remove the kernel source directory lead to another kernel Oops. --> Unable to unmount /mnt/hda8 either In hope my report will prove usefull. Notabene: I am currently unable to providing meaningful log reports such as syslog or dmesg. Don't hesitate to ask me for such reports at v.quequet-techniques@orange.fr if you feel necessary. Sincerely, Valentin QUEQUET
Thanks for this report. Without seeing the dmesg output, it is difficult to say exactly which problem you've hit. We do have a patch in testing for a false ENOSPC panic that will probably fix things for you. I'll post to this bug when it is available for broader testing.
Created attachment 20251 [details] My BTRFS filesystem module error report.
NOTE : THIS ADDITIONAL COMMENT RELATES TO THE ATTACHMENT I JUST POSTED A MINUTE EARLIER. bugme-daemon@bugzilla.kernel.org wrote : > http://bugzilla.kernel.org/show_bug.cgi?id=12555 > > > chris.mason@oracle.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|fs_btrfs@kernel- |chris.mason@oracle.com > |bugs.osdl.org | > Status|NEW |ASSIGNED > > > > > ------- Comment #1 from chris.mason@oracle.com 2009-01-28 08:39 ------- > Thanks for this report. Without seeing the dmesg output, it is difficult to > say exactly which problem you've hit. We do have a patch in testing for a > false ENOSPC panic that will probably fix things for you. I'll post to this > bug when it is available for broader testing. > > Hello, I didn't try your patch, but I experience similar BUG with Linux 2.6.29-rc5 . Under a newly-created BTRFS volume, I extracted the sources of linux-2.6.29-rc5, then I created an approx 400MB all-zeroes file in it and all went right. A minute later, I deleted that ~400MB file and I just tried to recreate it again (using dd bs=1M count=400 if=/dev/zero of=<DestFile_In_BTRFS_Volume>). The BUG appeared at re-creation attempt (of the ~400 MB 0ed file), leading to a series of PC-speaker beeps this time, plus the following dmesg output, in attached "btrfs_dmesg.txt" file, where the first 3 lines are due to normal BTRFS usage (no error). Please, consider studying the following attachment : btrfs_dmesg.txt . In hope my report will prove useful. Sincerely, Valentin QUEQUET
This bug #12555 might be coalesced with bug #12549. Sincerely, Valentin QUEQUET
We have a much larger effort in the final testing stages for improved ENOSPC handling. I'll post an update to this bug as soon as it is ready for general use.
chris, didn`t i see some ENOSPC fixes in the meantime? is time right for the reporter to give latest .31rc kernel a try ?