[RFC] remove delalloc accounting for __btrfs_remove_ordered_extent

I got below oops when doing file write with mount option max_extent=1M It appears the accouting is already done in set/clear/split/merge hooks and I don't see reason why we need do accouting in __btrfs_remove_ordered_extent again. Below patch makes my test work but please double check. [ 185.7763

Re: No space left on device, btrfsctl segmentation fault

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.

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/ FilesystemSize Used Avail Use% Mounted on /dev/sdi2 1.9T

Re: Reporting free space to userspace programs

Hi, in a long overdue followup to my previous email, I am sending a patch that modifies the result of running 'df' against a btrfs volume. I understand that, give the simplicity of 'df', there is not 'correct' solution - I do think however, that the changed output is more intuitive. Most important

Re: [PATCH] btrfs: use RB_ROOT to intialize rb_trees instead of setting rb_node to NULL

.315518] Modules linked in: [last unloaded: scsi_wait_scan] > > [5.315518] > > [5.315518] Pid: 1314, comm: mount Not tainted 2.6.33-rc8-next-20100223+ > > #21 /KVM > > [5.315518] RIP: 0010:[] [] > > rb_insert_color+0x20/0x120 > > [5.315518] RSP

Re: [PATCH] btrfs: use RB_ROOT to intialize rb_trees instead of setting rb_node to NULL

event_seqnum > [5.315518] CPU 0 > [5.315518] Modules linked in: [last unloaded: scsi_wait_scan] > [5.315518] > [5.315518] Pid: 1314, comm: mount Not tainted 2.6.33-rc8-next-20100223+ > #21 /KVM > [5.315518] RIP: 0010:[] [] > rb_insert_color+0x20/0x120 >

[PATCH] btrfs: use RB_ROOT to intialize rb_trees instead of setting rb_node to NULL

] CPU 0 [5.315518] Modules linked in: [last unloaded: scsi_wait_scan] [5.315518] [5.315518] Pid: 1314, comm: mount Not tainted 2.6.33-rc8-next-20100223+ #21 /KVM [5.315518] RIP: 0010:[] [] rb_insert_color+0x20/0x120 [5.315518] RSP: 0018:88003cc21a88 EFLAGS: 000

Re: [mount] commit intervall for metadata and btrfs - is it planned ?

On Wed, Feb 10, 2010 at 7:55 PM, Josef Bacik wrote: > On Wed, Feb 10, 2010 at 06:15:26PM +, Mat wrote: >> Hi guys, >> >> First off: you guys are doing amazing work ! >> >> btrfs "Better-FS" gets more and more stable, fast and space-efficient than >> all/most of the other filesystems :) >> >> >

Re: Kernel BUG on mounting BtrFS / after reboot

Alex Elsayed gmail.com> writes: > > Chris Mason oracle.com> writes: > > I think the btrfsck output is missing. It sounds like we'll survive if > > we just skip this part of the log replay. I'll cook a patch based on > > the btrfsck output. > > It was inline in my first message, immediately a