Btrfs devel - Feb 2010 - No space left on device, btrfsctl segmentation fault

Greetings!

I have a singe 2TB disk formatted with btrfs 0.19 on Ubuntu 10.04-alpha2:

# uname -a
Linux fan-ting 2.6.32-14-generic #20-Ubuntu SMP Sat Feb 20 05:18:19
UTC 2010 x86_64 GNU/Linux

# df -h /media/onlyhope/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdi2             1.9T  1.7T  197G  90% /media/onlyhope


I''m getting "no space left on device" errors when I try to
move files
to this volumes via rsync.

So I tried, as an experiment, to "defragment" the volume with
btrfsctl:

# btrfsctl -d /media/onlyhope
Segmentation fault


I am a btrfs newbie. Clearly I am doing something wrong. Any
suggestions for generating a more meaningful error report?

Thanks!!
--
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

I believe there is a kerneloops associated with this problem:

ProblemType: KernelOops
Annotation: Your system might become unstable now and might need to be
restarted.
Date: Tue Feb 23 22:40:53 2010
Failure: oops
OopsText:
 ------------[ cut here ]------------
 WARNING: at /build/buildd/linux-2.6.32/fs/btrfs/extent_io.c:3210
free_extent_buffer+0x31/0x40 [btrfs]()
 Hardware name: To Be Filled By O.E.M.
 Modules linked in: nfs btrfs zlib_deflate crc32c libcrc32c
binfmt_misc ppdev vboxnetflt vboxnetadp vboxdrv nfsd lockd nfs_acl
auth_rpcgss sunrpc exportfs snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm fbcon
tileblit font bitblit snd_seq_dummy softcursor lp nvidia(P) vga16fb
vgastate snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
parport snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc
psmouse serio_raw ohci1394 ieee1394 usbhid r8169 mii
 Pid: 4317, comm: ls Tainted: P      D W  2.6.32-14-generic #20-Ubuntu
 Call Trace:
  [<ffffffff81064f7b>] warn_slowpath_common+0x7b/0xc0
  [<ffffffff81064fd4>] warn_slowpath_null+0x14/0x20
  [<ffffffffa0eae441>] free_extent_buffer+0x31/0x40 [btrfs]
  [<ffffffffa0e741bd>] btrfs_release_path+0x1d/0x70 [btrfs]
  [<ffffffffa0e7459b>] btrfs_free_path+0x1b/0x40 [btrfs]
  [<ffffffffa0e9ac94>] btrfs_real_readdir+0x234/0x4f0 [btrfs]
  [<ffffffff81150c10>] ? filldir+0x0/0xe0
  [<ffffffffa0e992e4>] ? btrfs_dirty_inode+0x54/0x70 [btrfs]
  [<ffffffff8155ea1e>] ? _spin_lock+0xe/0x20
  [<ffffffff81156ead>] ? touch_atime+0x13d/0x180
  [<ffffffff81150c10>] ? filldir+0x0/0xe0
  [<ffffffff81150e90>] vfs_readdir+0xc0/0xe0
  [<ffffffff81151019>] sys_getdents+0x89/0xf0
  [<ffffffff8155eee5>] ? page_fault+0x25/0x30
  [<ffffffff810131f2>] system_call_fastpath+0x16/0x1b
 ---[ end trace 0fdd336562453361 ]---

Package: linux-image-2.6.32-14-generic
SourcePackage: linux
Tags: kernel-oops
--
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

The ''used'' output of df on a btrfs system does not take
metadata into
account. So the disk is really full. This is what my yesterdays path
is intended to fix - can you try it out?

On Wed, Feb 24, 2010 at 5:27 AM, Boyd Waters <waters.boyd@gmail.com>
wrote:
> I believe there is a kerneloops associated with this problem:
>
> ProblemType: KernelOops
> Annotation: Your system might become unstable now and might need to be
> restarted.
> Date: Tue Feb 23 22:40:53 2010
> Failure: oops
> OopsText:
>  ------------[ cut here ]------------
>  WARNING: at /build/buildd/linux-2.6.32/fs/btrfs/extent_io.c:3210
> free_extent_buffer+0x31/0x40 [btrfs]()
>  Hardware name: To Be Filled By O.E.M.
>  Modules linked in: nfs btrfs zlib_deflate crc32c libcrc32c
> binfmt_misc ppdev vboxnetflt vboxnetadp vboxdrv nfsd lockd nfs_acl
> auth_rpcgss sunrpc exportfs snd_hda_codec_realtek snd_hda_intel
> snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm fbcon
> tileblit font bitblit snd_seq_dummy softcursor lp nvidia(P) vga16fb
> vgastate snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
> parport snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc
> psmouse serio_raw ohci1394 ieee1394 usbhid r8169 mii
>  Pid: 4317, comm: ls Tainted: P      D W  2.6.32-14-generic #20-Ubuntu
>  Call Trace:
>  [<ffffffff81064f7b>] warn_slowpath_common+0x7b/0xc0
>  [<ffffffff81064fd4>] warn_slowpath_null+0x14/0x20
>  [<ffffffffa0eae441>] free_extent_buffer+0x31/0x40 [btrfs]
>  [<ffffffffa0e741bd>] btrfs_release_path+0x1d/0x70 [btrfs]
>  [<ffffffffa0e7459b>] btrfs_free_path+0x1b/0x40 [btrfs]
>  [<ffffffffa0e9ac94>] btrfs_real_readdir+0x234/0x4f0 [btrfs]
>  [<ffffffff81150c10>] ? filldir+0x0/0xe0
>  [<ffffffffa0e992e4>] ? btrfs_dirty_inode+0x54/0x70 [btrfs]
>  [<ffffffff8155ea1e>] ? _spin_lock+0xe/0x20
>  [<ffffffff81156ead>] ? touch_atime+0x13d/0x180
>  [<ffffffff81150c10>] ? filldir+0x0/0xe0
>  [<ffffffff81150e90>] vfs_readdir+0xc0/0xe0
>  [<ffffffff81151019>] sys_getdents+0x89/0xf0
>  [<ffffffff8155eee5>] ? page_fault+0x25/0x30
>  [<ffffffff810131f2>] system_call_fastpath+0x16/0x1b
>  ---[ end trace 0fdd336562453361 ]---
>
> Package: linux-image-2.6.32-14-generic
> SourcePackage: linux
> Tags: kernel-oops
> --
> 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
>
--
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

Can someone please explain why it takes btrfs 10% of a 2TB disk *just*
for metadata ? I''d say 1% is too much
--
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, Feb 23, 2010 at 10:39:33PM -0500, Boyd Waters
wrote:
> Greetings!
> 
> I have a singe 2TB disk formatted with btrfs 0.19 on Ubuntu 10.04-alpha2:
> 
> # uname -a
> Linux fan-ting 2.6.32-14-generic #20-Ubuntu SMP Sat Feb 20 05:18:19
> UTC 2010 x86_64 GNU/Linux
> 
> # df -h /media/onlyhope/
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdi2             1.9T  1.7T  197G  90% /media/onlyhope
> 
> 
> I''m getting "no space left on device" errors when I try
to move files
> to this volumes via rsync.
> 
> So I tried, as an experiment, to "defragment" the volume with
btrfsctl:
> 
> # btrfsctl -d /media/onlyhope
> Segmentation fault
> 
> 
> I am a btrfs newbie. Clearly I am doing something wrong. Any
> suggestions for generating a more meaningful error report?
> 
You''ll want to try

btrfs-vol -b /media/onlyhope

that will balance the metadata/data space and hopefully let you get back some of
your space.  Just a warning, that will take _forever_, and then it still may
hang.  You''ll want to watch dmesg, if it says something like

moving <number> extents

and <number> does not change for like 20 lines, then its hung and you need
to
reboot.  When you reboot and remount it will hang for a bit, thats ok its just
cleaning things up, and then you should be good to go.  Thanks,

Josef
--
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

Thanks for the suggestions, everyone!

I copied the data from the 2TB btrfs disk to an identical disk (same
make and model) formatted with ext4:

/dev/sdi2             1.9T  1.7T  197G  90% /media/onlyhope
/dev/sdg1             1.8T  1.7T   71G  96% /mnt/newhope

The metadata "overhead" for btrfs is a bit more, but it isn''t
outrageous IMHO.

=
Re-balancing the tree with "btrfs-vol -b" sounds about right, both in
terms of time and stability. I haven''t tried that yet, but I can
report on that experiment.

Leszek wrote:
> The ''used'' output of df on a btrfs system does not take
metadata into
account. So the disk is really full. This is what my yesterdays path
is intended to fix - can you try it out?
>
I would like to try this patch, I apologize for being so new to btrfs
development: can you tell me where to find the patch? Is it for btrfs
tools or the btrfs itself? I will try to find it, but a quick pointer
to it will help me test!

Thanks again!
--
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

The patch is here: http://patchwork.kernel.org/patch/81547/ , it''s for
kernel.

But I have just seen weird behaviour with my btrfs, I''m not sure
whether it''s my patch or the new changes I have pulled from git -
I''d
recommend you wait with trying out this patch until someone diagnoses
what failed with my fs :-)

And as for metadata size - "btrfs-vol -b" reduces the metadata amount
by a large amount for filesystems containing huge files.

On Wed, Feb 24, 2010 at 8:20 PM, Boyd Waters <waters.boyd@gmail.com>
wrote:
> Thanks for the suggestions, everyone!
>
> I copied the data from the 2TB btrfs disk to an identical disk (same
> make and model) formatted with ext4:
>
> /dev/sdi2             1.9T  1.7T  197G  90% /media/onlyhope
> /dev/sdg1             1.8T  1.7T   71G  96% /mnt/newhope
>
> The metadata "overhead" for btrfs is a bit more, but it
isn''t outrageous IMHO.
>
> =>
> Re-balancing the tree with "btrfs-vol -b" sounds about right,
both in
> terms of time and stability. I haven''t tried that yet, but I can
> report on that experiment.
>
> Leszek wrote:
>> The ''used'' output of df on a btrfs system does not
take metadata into
> account. So the disk is really full. This is what my yesterdays path
> is intended to fix - can you try it out?
>>
>
> I would like to try this patch, I apologize for being so new to btrfs
> development: can you tell me where to find the patch? Is it for btrfs
> tools or the btrfs itself? I will try to find it, but a quick pointer
> to it will help me test!
>
> Thanks again!
> --
> 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
>
--
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