On Tue, May 18, 2010 at 02:03:49PM +0200, Jakob Unterwurzacher wrote:
On 18/05/10 02:59, Chris Mason wrote:
Ok, I upgraded to 2.6.34 final and switched to defconfig.
I only did the rename test ( i.e. no overwrite ), the window is now
1.1s, both with vanilla and with the patch.
Thanks,
* Chris Mason chris.ma...@oracle.com [100518 09:13]:
I'm more than open to discussion on this one, but I don't see how:
Should be expected to write 1GB of data.
++
Please don't mess up BTRFS because older, less better things are messed
up in certain ways. If we're just going to continually
On 18/05/10 15:13, Chris Mason wrote:
The thing is that different apps have a different version of 'right'. Rename
is atomically replacing one file with another, and I completely agree
that when we have an established file on disk, we shouldn't replace it
with something that is potentially
On 05/18/10 15:28, Oystein Viggen wrote:
* [Chris Mason]
I'm more than open to discussion on this one, but I don't see how:
rm -f foo2
dd if=/dev/zero of=foo bs=1M count=1000
mv foo foo2
Should be expected to write 1GB of data.
IIRC, the answer you're looking for is it did with ext3 in
On Tue, May 18, 2010 at 05:57:49PM +0200, Jakob Unterwurzacher wrote:
On 18/05/10 16:36, Chris Mason wrote:
The idea would be to delay the rename hitting the disk until the data
has been written anyway.
The mv would return immediately, and someday, after the data has been
written to
On 18/05/10 18:10, Chris Mason wrote:
I'm not sure how much memory a queued rename takes up, but the time that
would be spent flushing it to disk would then be spent flushing file
data, draining the write buffer and freeing memory, no?
That would be writing to disk
On Tue, May 18, 2010 at 07:00:57PM -0400, Ric Wheeler wrote:
Just to weigh in here, I think that you have the right behaviour
already. If an application wants to force this to sync the data to disk,
it should use fsync() after the rename.
Actually, it pretty much has to fsync before the
Chris Mason wrote:
On Tue, May 18, 2010 at 02:03:49PM +0200, Jakob Unterwurzacher wrote:
On 18/05/10 02:59, Chris Mason wrote:
Ok, I upgraded to 2.6.34 final and switched to defconfig.
I only did the rename test ( i.e. no overwrite ), the window is now
1.1s, both with vanilla and with the
Hi!
Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
solve them all. And it nearly does! Now I wonder if the remaining 0.2
seconds window of exposing 0-size files could be closed too.
I tested using two simple scripts (attached for reference) on kernel
2.6.34-rc7:
- rentest
On Mon, May 17, 2010 at 08:04:21PM +0200, Jakob Unterwurzacher wrote:
Hi!
Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
solve them all. And it nearly does! Now I wonder if the remaining 0.2
seconds window of exposing 0-size files could be closed too.
I tested using
On Mon, May 17, 2010 at 08:04:21PM +0200, Jakob Unterwurzacher wrote:
Hi!
Following Ubuntu's dpkg+ext4 problems I wanted to see if btrfs would
solve them all. And it nearly does! Now I wonder if the remaining 0.2
seconds window of exposing 0-size files could be closed too.
That should be a
On Tue, May 18, 2010 at 02:14:05AM +0200, Jakob Unterwurzacher wrote:
On 17/05/10 21:36, Chris Mason wrote:
That should be a zero second window, we try to force things to disk
during renames.
Could you please try this patch:
diff --git a/fs/btrfs/ordered-data.c
12 matches
Mail list logo
