Re: Kernel error during btrfs balance

Hi, It took me a couple of days, because I needed to patch my kernel first and then issue a rebalance, which ran for more than two days. Nevertheless, the rebalance succeeded without any kernel BUG-messages, so apparently your patch works! I noticed that at first, the messages were like this:

Re: Kernel error during btrfs balance

On Wed, Jan 26, 2011 at 10:04:02AM +0100, Erik Logtenberg wrote: Hi, It took me a couple of days, because I needed to patch my kernel first and then issue a rebalance, which ran for more than two days. Nevertheless, the rebalance succeeded without any kernel BUG-messages, so apparently your

Re: Kernel error during btrfs balance

[104178.827624] entry offset 8891924480, bytes 4096, bitmap yes [104178.827626] block group has cluster?: no [104178.827628] 0 blocks of free space at or bigger than bytes is [104178.827631] block group 17213423616 has 5368709120 bytes, 5368709120 used 0 pinned 0 reserved [104178.827634]

Re: Kernel error during btrfs balance

Yesterday I reported a similar problem in this mailing list, in the thread version. Running kernel 2.6.37 didn't show this error, but running kernel 2.6.38- rc2 ended with errors. Viele Gruesse! Helmut Ah, indeed, just like you I use 2.6.38-rc2. Or to be more precise:

Re: version (was: btrfs, broken design?)

On 01/21/2011 03:32 PM, Diego Calleja wrote: On Viernes, 21 de Enero de 2011 10:54:00 Helmut Hullen escribió: And I never have seen somethin like Changelog - that would be fine too. Check the wiki, I keep that updated: https://btrfs.wiki.kernel.org/index.php/Main_Page#News I like the

[PATCH] Btrfs: Fix balance panic

Mark the cloned backref_node as checked in clone_backref_node() Signed-off-by: Yan, Zheng zheng.z@intel.com --- diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 045c9c2..bef9c22 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -1157,6 +1157,7 @@ static int

Re: version (was: btrfs, broken design?)

On Miércoles, 26 de Enero de 2011 11:13:20 Erik Logtenberg escribió: Diego, pls don't read anything negative in my comments, I enjoy and respect your work very much! If you could find time to add those latest changes to the wiki, it would be greatly appreciated. Thanks for your suggestion,

Re: [PATCH] Btrfs: Fix balance panic

Hallo, Yan,, Du meintest am 26.01.11: Mark the cloned backref_node as checked in clone_backref_node() Signed-off-by: Yan, Zheng zheng.z@intel.com -+- diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 045c9c2..bef9c22 100644 -+- a/fs/btrfs/relocation.c +++

btrfs BUG during Ceph cosd open() syscall

Hi, I got this kernel BUG on a server running multiple Ceph cosd instances, during a heavy write load generated by multiple Ceph clients. The server was running the current ceph unstable kernel (a3f5274e535 in git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git). Please let me

Who wants metadata image from botched filesystem?

Hello. So I had the filesystem that became broken. on 2.6.37 with for-linus unstable, when accessing some directories, it was hanging hard. I created the metadata image and can put it somewhere if you want to use it for something. Thanks. -- This message represents the official view of the

Re: [RFC][PATCH] Btrfs: New inode number allocator

On 01/26/2011 02:53 AM, Li Zefan wrote: Here comes the compatability issue. It's fine to mount old btrfs, because we'll just use the original way to find free ino. But we can't mount new btrfs in older kernels, because the OFFSET makes highest objectid overflow when it is cast to unsigned long

Re: Atomic file data replace API

On Wed, Jan 26, 2011 at 8:30 PM, Chris Mason chris.ma...@oracle.com wrote: My answer hasn't really changed ;)  Replacing file data is a common operation, but it is still surprisingly complex.  Again, the truncate is O(size of the file) and it is actually impossible to do this atomically in

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

Hi, attached is the answer from Jari Ruusu, (one of?!) the main developer of loop-aes. It seems that checking if a loop device is mounted following the link isn't the best idea :) I'll have time to look deeper into his example about the 14.02. I'll then try to fix that issue in mkfs.btrfs. If

2.6.38-rc2 oops's when rebalancing on different size drives (was Re: version)

On 26/01/11 01:37, Helmut Hullen wrote: bio too big device sdc (256 240) bio too big device sdc (256 240) bio too big device sdc (256 240) bio too big device sdc (256 240) Oh dear, those are errors from the block layer, looks like btrfs is doing something wrong there.. :-(

Re: full btrfs partition, became unmountable (+ a solution that thankfully worked for me)

Hello Shawn, it's now performing a sequential read of the volume, which will probably take significantly more time for you than for me (where I was dealing with an image of a 16GB SD card, stored on a recent mechanical SATA disk). I'm a bit confused by what happens while reading the potential

Re: [RFC][PATCH] Btrfs: New inode number allocator

Chris Mason wrote: Excerpts from Li Zefan's message of 2011-01-25 20:53:00 -0500: (WARNING: this patch is not completed or well-tested) We used to allocate inode number by searching through inode items, but it made the allocation slower and slower as more and more files created. The

Re: full btrfs partition, became unmountable (+ a solution that thankfully worked for me)

any chance of getting a little more informative output? I started the command at about 2250 Eastern and now at 0117 Eastern the command is still running and all of the attached output happened in the first few minutes (under 5). btrfsck /dev/sde trying potential super #0 at bytenr 65536 super

Re: version

Excerpts from Helmut Hullen's message of 2011-01-25 09:37:00 -0500: crashes with the dmesg lines - dmesg --- bio too big device sdc (256 240) bio too big device sdc (256 240) bio too big device sdc (256 240) bio too big device sdc (256 240)