On 14/02/11 17:58, Marti Raudsepp wrote:
On Mon, Feb 14, 2011 at 17:01, Chris Mason chris.ma...@oracle.com wrote:
Or, it could just be delalloc ;)
I suspect delalloc. After creating the file, filefrag reports 1
extent found, but for some reason it doesn't actually print out
details of the
On Tue, Feb 15, 2011 at 11:30:38AM +, Pádraig Brady wrote:
On 14/02/11 17:58, Marti Raudsepp wrote:
On Mon, Feb 14, 2011 at 17:01, Chris Mason chris.ma...@oracle.com wrote:
Or, it could just be delalloc ;)
I suspect delalloc. After creating the file, filefrag reports 1
extent
Excerpts from Josef Bacik's message of 2011-02-13 11:13:30 -0500:
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
On Mon, Feb 14, 2011 at 17:01, Chris Mason chris.ma...@oracle.com wrote:
Or, it could just be delalloc ;)
I suspect delalloc. After creating the file, filefrag reports 1
extent found, but for some reason it doesn't actually print out
details of the extent.
After a sync call, the extent appears
Excerpts from Marti Raudsepp's message of 2011-02-14 12:58:17 -0500:
On Mon, Feb 14, 2011 at 17:01, Chris Mason chris.ma...@oracle.com wrote:
Or, it could just be delalloc ;)
I suspect delalloc. After creating the file, filefrag reports 1
extent found, but for some reason it doesn't
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
