Btrfs devel - May 2009 - BUG at fs/buffer.c:2933 during umount

Hi,

I could not find this anywhere else reported, so here we go:
creating a new btrfs filesystem (btrfs-progs-unstable from git) and 
mounting it succeeds, unmounting however fails with the kernel messages 
attached to this mail. After that, I can still read and write to the 
btrfs mount, but e.g. /bin/sync never finishes, sysrq-s never reports 
"Sync complete".

I''m using a vanilla kernel, yesterday''s git version 
and I *think* I remember having creating btrfs filesystems before (2.6.29, 
IIRC) and being able to umount them without problems. But I don''t know
for
sure...yet.

Christian.

On Tue, 2009-05-05 at 12:23 -0700, Christian Kujau
wrote:
> Hi,
> 
> I could not find this anywhere else reported, so here we go:
> creating a new btrfs filesystem (btrfs-progs-unstable from git) and 
> mounting it succeeds, unmounting however fails with the kernel messages 
> attached to this mail. After that, I can still read and write to the 
> btrfs mount, but e.g. /bin/sync never finishes, sysrq-s never reports 
> "Sync complete".
> 
> I''m using a vanilla kernel, yesterday''s git version 
> and I *think* I remember having creating btrfs filesystems before (2.6.29, 
> IIRC) and being able to umount them without problems. But I don''t
know for
> sure...yet.
Somehow xen is turning a barrier request into an IO error.  That''s
really quite strange, but you can mount -o nobarrier.

-chris



--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 5 May 2009, Chris Mason wrote:
> Somehow xen is turning a barrier request into an IO error.  That''s
> really quite strange, but you can mount -o nobarrier.
Thanks for the quick reply - yes, that helped. So, is that something I 
should report to the Xen folks? These "other filesystems" I can
unmount
with no BUG :-)


I just noted something else, but completely unrelated to that barrier 
stuff:

# ls -ld /mnt/d*
dr-xr-xr-x 1 root root    0 Jan  1  1970 /mnt/d1
drwxr-xr-x 3 root root 4096 May  5 21:45 /mnt/d2
# grep mnt/d /proc/mounts 
/dev/xvdb /mnt/d1 btrfs rw,relatime,nobarrier 0 0
/dev/xvdc /mnt/d2 ext3 rw,relatime,errors=continue,data=writeback 0 0

How comes btrfs thinks it has been created at the beginning of time?

Christian.
-- 
Strong cryptography does not exist for Bruce Schneier. There is only weak and
less weak cryptography.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 2009-05-05 at 12:51 -0700, Christian Kujau
wrote:
> On Tue, 5 May 2009, Chris Mason wrote:
> > Somehow xen is turning a barrier request into an IO error. 
That''s
> > really quite strange, but you can mount -o nobarrier.
> 
> Thanks for the quick reply - yes, that helped. So, is that something I 
> should report to the Xen folks? These "other filesystems" I can
unmount
> with no BUG :-)
For ext3, mount -o barrier=1 and you should see something exciting.  It
won''t BUG because ext3 isn''t as serious about telling the
users about IO
problems as we are, but you should at least see messages.
> 
> 
> I just noted something else, but completely unrelated to that barrier 
> stuff:
> 
> # ls -ld /mnt/d*
> dr-xr-xr-x 1 root root    0 Jan  1  1970 /mnt/d1
> drwxr-xr-x 3 root root 4096 May  5 21:45 /mnt/d2
> # grep mnt/d /proc/mounts 
> /dev/xvdb /mnt/d1 btrfs rw,relatime,nobarrier 0 0
> /dev/xvdc /mnt/d2 ext3 rw,relatime,errors=continue,data=writeback 0 0
> 
> How comes btrfs thinks it has been created at the beginning of time?
The mkfs.btrfs command needs to properly set the date on the root
directory.  Sorry, I never noticed that one.

-chris


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 5 May 2009, Chris Mason wrote:
> For ext3, mount -o barrier=1 and you should see something exciting.  It
> won''t BUG because ext3 isn''t as serious about telling the
users about IO
> problems as we are, but you should at least see messages.
With that option, ext3 gives a waring, yes:

[ 1743.370971] JBD: barrier-based sync failed on xvdc - disabling barriers

Ext4 seems to enable barriers right away and when I actually write to the 
filesystem, it emits a warning indeed:

# umount /mnt/d2
[...]
[ 1409.043735] JBD: barrier-based sync failed on xvdc:8 - disabling barriers
[ 1413.700390] EXT4-fs: mballoc: 1531 blocks 46 reqs (24 success)
[ 1413.700406] EXT4-fs: mballoc: 23 extents scanned, 1 goal hits, 23 2^N hits, 0
breaks, 0 lost
[ 1413.700415] EXT4-fs: mballoc: 2 generated and it took 4884
[ 1413.700421] EXT4-fs: mballoc: 1212 preallocated, 690 discarded

I still find the BUG somehow...misleading. An error message seems to be 
more appropriate.

Christian.
-- 
The universe was created to serve as Bruce Schneier''s crib text.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html