Re: BTRFS fsck tool

2011-03-10 Thread Chris Mason
Excerpts from Alexey A Nikitin's message of 2011-03-10 12:30:54 -0500: > 2011/3/10 Chris Mason > > > > Which kernel were you on?  Was btrfs directly accessing the disks or > > were things like LVM in use? > > Recent kernels (.37 and higher) have improved support for barriers in > > LVM and friends

Re: BTRFS fsck tool

2011-03-10 Thread Alexey A Nikitin
2011/3/10 Chris Mason > > Which kernel were you on?  Was btrfs directly accessing the disks or > were things like LVM in use? > Recent kernels (.37 and higher) have improved support for barriers in > LVM and friends, but btrfs directly using the disks should have been > safe for a long time. Now

Re: resize ate my root node

2011-03-10 Thread Chris Mason
Excerpts from Peter Stuge's message of 2011-03-10 08:45:09 -0500: > Chris Mason wrote: > > Which tool and which version of the tool did you use to delete the > > partition? > > fdisk from util-linux-2.18 Straight from util-linux, or with distro patches? > > The non-working partition was deleted

Re: BTRFS fsck tool

2011-03-10 Thread Chris Mason
Excerpts from Peter Stuge's message of 2011-03-10 08:29:37 -0500: > Chris Mason wrote: > > Cutting the power isn't problem unless you're using something > > where cache flushes are not supported. > > Nod. I've had very abrupt system outage before, without problems. > > > Which kernel were you on?

Re: resize ate my root node

2011-03-10 Thread Peter Stuge
Chris Mason wrote: > Which tool and which version of the tool did you use to delete the > partition? fdisk from util-linux-2.18 The non-working partition was deleted and the current one created with fdisk from util-linux-2.14.2. > > It's a 64GB CF card with two partitions; one 40MB ext2 and "th

Re: BTRFS fsck tool

2011-03-10 Thread Peter Stuge
Chris Mason wrote: > Cutting the power isn't problem unless you're using something > where cache flushes are not supported. Nod. I've had very abrupt system outage before, without problems. > Which kernel were you on? 2.6.38-rc6 + wireless-testing.git > Was btrfs directly accessing the disks

Re: resize ate my root node

2011-03-10 Thread Chris Mason
Excerpts from Peter Stuge's message of 2011-03-10 01:23:33 -0500: > Hi Chris, > > Chris Mason wrote: > > > I ran btrfsctl resize -r -3gb /dev/sda2 using wireless-testing.git > > > based on 2.6.38-rc6 and all seemed good. df reported reduced size so > > > I repartitioned and rebooted. Filesystem ca

Re: resize ate my root node

2011-03-10 Thread Chris Mason
Excerpts from Peter Stuge's message of 2011-03-10 01:23:33 -0500: > Hi Chris, > > Chris Mason wrote: > > > I ran btrfsctl resize -r -3gb /dev/sda2 using wireless-testing.git > > > based on 2.6.38-rc6 and all seemed good. df reported reduced size so > > > I repartitioned and rebooted. Filesystem ca

Re: BTRFS fsck tool

2011-03-10 Thread Chris Mason
Excerpts from Peter Stuge's message of 2011-03-08 01:52:55 -0500: > Hi, > > Alexey A Nikitin wrote: > > I went experimenting with btrfs RAID0 on my USB setup .. because > > I'm a reckless experimenter when it doesn't involve production > > systems. > > I encountered the same broken root node issu

Re: [PATCH 1/2] Btrfs: fix OOPS of empty filesystem after balance

2011-03-10 Thread Chris Mason
Excerpts from liubo's message of 2011-03-10 03:50:27 -0500: > On 03/07/2011 10:13 AM, liubo wrote: > > btrfs will remove unused block groups after balance. > > When a empty filesystem is balanced, the block group with tag "DATA" may be > > dropped, and after umount and mount again, it will not find

Re: BTRFS fsck tool

2011-03-10 Thread Clemens Eisserer
Well, the missing file-system checker is the main reason I don't use btrfs in production environments. The other issue are servere performance problems in corner cases (e.g. when deleting 15GB data takes 100% cpu and hours) - Clemens 2011/3/8 Peter Stuge : > Hi, > > Alexey A Nikitin wrote: >> I w

Re: [PATCH 1/2] Btrfs: fix OOPS of empty filesystem after balance

2011-03-10 Thread liubo
On 03/07/2011 10:13 AM, liubo wrote: > btrfs will remove unused block groups after balance. > When a empty filesystem is balanced, the block group with tag "DATA" may be > dropped, and after umount and mount again, it will not find "DATA" space_info > and lead to OOPS. > So we initial the necessary