xfs
[Top] [All Lists]

Re: drastic changes to allocsize semantics in or around 2.6.38?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: drastic changes to allocsize semantics in or around 2.6.38?
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Sun, 22 May 2011 09:59:55 +0200
Cc: Marc Lehmann <schmorp@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20110522020024.GZ32466@dastard>
References: <20110520005510.GA15348@xxxxxxxxxx> <20110520025659.GO32466@dastard> <20110520154920.GD5828@xxxxxxxxxx> <20110521004544.GT32466@dastard> <20110521013604.GC10971@xxxxxxxxxx> <20110521031537.GV32466@dastard> <20110521041652.GA18375@xxxxxxxxxx> <20110522020024.GZ32466@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On 22.05.2011 12:00, Dave Chinner wrote:
> 
> I don't really care what you think the problem is based on what
> you've read in this email thread, or for that matter how you think
> we should fix it. What I really want is your test cases that
> reproduce the problem so I can analyse it for myself. Once I
> understand what is going on, then we can talk about what the real
> problem is and how to fix it.

What would interest me is why the following creates files with large 
preallocations.

cp -a <somedir> target
rm -rf target
cp -a <somedir> target

After the first copy everything looks normal, `du` is about the 
original value.

After the second run a `du` shows a much higher value, until the 
preallocation is shrunk away.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

<Prev in Thread] Current Thread [Next in Thread>