On Sun, Feb 13, 2011 at 05:49:42PM +0200, Marti Raudsepp wrote:
Hi list!
It seems I have found a serious regression in compressed btrfs in
kernel 2.6.37. When creating a small file (less than the block size)
and then cp/mv it to *another* file system, an appropriate number of
zeroes gets
On Sun, Feb 13, 2011 at 06:07:36PM +0200, Marti Raudsepp wrote:
On Sun, Feb 13, 2011 at 17:57, Josef Bacik jo...@redhat.com wrote:
Does the same problem happen when you use cp --sparse=never?
You are right. cp --sparse=never does not cause data loss.
So fiemap probably isn't doing the
On Sun, Feb 13, 2011 at 05:49:42PM +0200, Marti Raudsepp wrote:
Hi list!
It seems I have found a serious regression in compressed btrfs in
kernel 2.6.37. When creating a small file (less than the block size)
and then cp/mv it to *another* file system, an appropriate number of
zeroes gets
Hi everyone, I'm experimenting with btrfs but I have some question
regarding subvolumes.
First: In the / filesystem I create a subvolume named /home. As soon as
the subvolume is created, I can already see the entry point in /home
without having to mount it separately. Is that expected?
Mounting
On Sun, Feb 13, 2011 at 05:46:46PM +0100, Yuri D'Elia wrote:
Hi everyone, I'm experimenting with btrfs but I have some question
regarding subvolumes.
First: In the / filesystem I create a subvolume named /home. As soon as
the subvolume is created, I can already see the entry point in /home
On Sun, Feb 13, 2011 at 06:49:58PM +0100, Yuri D'Elia wrote:
On Sun, 13 Feb 2011 17:30:59 +, Hugo Mills wrote:
First: In the / filesystem I create a subvolume named /home. As soon as
the subvolume is created, I can already see the entry point in /home
without having to mount it
(2011/02/12 20:17), Yoshinori Sano wrote:
To make Btrfs code more robust, several return value checks where memory
allocation can fail are introduced. I use BUG_ON where I don't know how
to handle the error properly, which increases the number of using the
notorious BUG_ON, though.
I add the check on the return value of alloc_extent_map() to several places.
In addition, alloc_extent_map() returns only the address or NULL.
Therefore, check by IS_ERR() is unnecessary. So, I remove IS_ERR() checking.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/extent-tree.c
Pádraig Brady wrote:
Unfortunately, after checking BTRFS I see that fiemap
behaves differently to EXT4. IMHO the EXT4 operation
seems correct, and gives full info about the structure
of a file, which cp for example can use to efficiently
and accurately reproduce the structure at the
