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

2011-02-11 Thread Felix Blanke
Hi, are you sure that patch is in the kernel? I'm using 2.6.37 and don't have those attribues in my /sys. Felix On 10. February 2011 - 13:29, Petr Uzel wrote: Date: Thu, 10 Feb 2011 13:29:27 +0100 From: Petr Uzel petr.u...@suse.cz To: Chris Samuel ch...@csamuel.org Cc: Felix Blanke

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

2011-02-11 Thread Milan Broz
On 02/11/2011 08:23 PM, Felix Blanke wrote: What do you mean with configured? I'm using loop devices with loop aes, and I've looked into /sys for a device which is actually in use. Ehm. It is really Loop-AES? Then ask author to backport it there, Loop-AES is not mainline code. He usually

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

2011-02-11 Thread Felix Blanke
Yeah, for me its loop-aes. Ah ok, didn't knew that it replaces that whole loop thing :) Felix On Feb 11, 2011 8:32 PM, Milan Broz mb...@redhat.com wrote: On 02/11/2011 08:23 PM, Felix Blanke wrote: What do you mean with configured? I'm using loop devices with loop aes, and I've looked into

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

2011-02-10 Thread Petr Uzel
On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote: /* * CC'd to linux-kernel in case they have any feedback on this. * * Long thread, trying to work out why mkfs.btrfs failed to * make a filesystem on an encrypted loopback mount called * /dev/loop2. Cause turned out to be

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

2011-01-26 Thread Felix Blanke
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