On 03/06/2017 08:27 PM, Jens Axboe wrote:
On 03/06/2017 11:17 AM, Avi Kivity wrote:
On 03/06/2017 07:06 PM, Jens Axboe wrote:
On 03/06/2017 09:59 AM, Avi Kivity wrote:
On 03/06/2017 06:08 PM, Jens Axboe wrote:
On 03/06/2017 08:59 AM, Avi Kivity wrote:
On 03/06/2017 05:38 PM, Jens Axboe
On 03/06/2017 07:06 PM, Jens Axboe wrote:
On 03/06/2017 09:59 AM, Avi Kivity wrote:
On 03/06/2017 06:08 PM, Jens Axboe wrote:
On 03/06/2017 08:59 AM, Avi Kivity wrote:
On 03/06/2017 05:38 PM, Jens Axboe wrote:
On 03/06/2017 08:29 AM, Avi Kivity wrote:
On 03/06/2017 05:19 PM, Jens Axboe
On 03/06/2017 06:08 PM, Jens Axboe wrote:
On 03/06/2017 08:59 AM, Avi Kivity wrote:
On 03/06/2017 05:38 PM, Jens Axboe wrote:
On 03/06/2017 08:29 AM, Avi Kivity wrote:
On 03/06/2017 05:19 PM, Jens Axboe wrote:
On 03/06/2017 01:25 AM, Jan Kara wrote:
On Sun 05-03-17 16:56:21, Avi Kivity
On 03/06/2017 05:38 PM, Jens Axboe wrote:
On 03/06/2017 08:29 AM, Avi Kivity wrote:
On 03/06/2017 05:19 PM, Jens Axboe wrote:
On 03/06/2017 01:25 AM, Jan Kara wrote:
On Sun 05-03-17 16:56:21, Avi Kivity wrote:
The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if
any
On 03/06/2017 05:19 PM, Jens Axboe wrote:
On 03/06/2017 01:25 AM, Jan Kara wrote:
On Sun 05-03-17 16:56:21, Avi Kivity wrote:
The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if
any of these conditions are met. This way userspace can push most
of the write()s to the kernel
On 03/06/2017 10:25 AM, Jan Kara wrote:
On Sun 05-03-17 16:56:21, Avi Kivity wrote:
The goal of the patch series is to return -EAGAIN/-EWOULDBLOCK if
any of these conditions are met. This way userspace can push most
of the write()s to the kernel to the best of its ability to complete
On 03/01/2017 01:36 AM, Goldwyn Rodrigues wrote:
This series adds nonblocking feature to asynchronous I/O writes.
io_submit() can be delayed because of a number of reason:
- Block allocation for files
- Data writebacks for direct I/O
- Sleeping because of waiting to acquire i_rwsem
-
On Sat, Apr 21, 2012 at 3:15 AM, Chris Mason chris.ma...@oracle.com wrote:
Are there plans to allow per-subvolume nodatasum/nodatacow?
It can be set on a per file basis, let me push out a commit to btrfs
progs with ioctls to set it.
Did this not happen, or am I barking up the wrong
On Fri, Apr 20, 2012 at 12:12 PM, David Sterba d...@jikos.cz wrote:
On Fri, Apr 20, 2012 at 11:19:39AM +0300, Avi Kivity wrote:
/dev/mapper/luks-blah / btrfs
subvol=/rootvol 1 1
/dev/mapper/luks-blah /var/lib/libvirt/images btrfs
nodatasum,nodatacow,subvol
On 03/13/2012 02:04 AM, Chris Mason wrote:
On Mon, Mar 12, 2012 at 09:32:54PM +0200, Avi Kivity wrote:
Because I'm such a btrfs fanboi I'm running btrfs on my /, all past
experience notwithstanding. In an attempt to recover some performance,
I enabled autodefrag, and got this in return
Because I'm such a btrfs fanboi I'm running btrfs on my /, all past
experience notwithstanding. In an attempt to recover some performance,
I enabled autodefrag, and got this in return:
[567304.937620] [ cut here ]
[567304.938525] kernel BUG at fs/btrfs/inode.c:1588!
On Mon, Oct 3, 2011 at 8:07 PM, Avi Kivity avi.kiv...@gmail.com wrote:
Thats -EIO, is there any messages before the bug? Thanks,
Not that I recall. I'll check again when I'm near the poor thing again.
Confirmed - that's the first relevant message.
As to -EIO, I dd'ed the entire volume
On Tue, Oct 4, 2011 at 4:39 PM, Avi Kivity avi.kiv...@gmail.com wrote:
On Mon, Oct 3, 2011 at 8:07 PM, Avi Kivity avi.kiv...@gmail.com wrote:
Thats -EIO, is there any messages before the bug? Thanks,
Not that I recall. I'll check again when I'm near the poor thing again.
Confirmed
On Tue, Oct 4, 2011 at 10:01 PM, Josef Bacik jo...@redhat.com wrote:
On 10/04/2011 03:50 PM, Avi Kivity wrote:
Yup I would love to investigate this, what kind of snapshot?
LVM snapshot.
Did you dd
the drive or soemthing? Let me know where to pull it down.
Um, it's my /home. It's
On Mon, Oct 3, 2011 at 4:34 PM, Josef Bacik jo...@redhat.com wrote:
On 09/30/2011 05:40 PM, Avi Kivity wrote:
On Wed, Aug 24, 2011 at 12:08 AM, Avi Kivity avi.kiv...@gmail.com wrote:
This is fixed upstream, I've sent the patch to -stable so hopefully it
will show up in fedora soon
Thats -EIO, is there any messages before the bug? Thanks,
Not that I recall. I'll check again when I'm near the poor thing again.
Confirmed - that's the first relevant message.
As to -EIO, I dd'ed the entire volume and no errors were found.
--
To unsubscribe from this list: send the line
On Wed, Aug 24, 2011 at 12:08 AM, Avi Kivity avi.kiv...@gmail.com wrote:
This is fixed upstream, I've sent the patch to -stable so hopefully it
will show up in fedora soon, but in the meantime can you try Linus's
tree and verify that it fixes it? Thanks,
Thanks, it appears to be fixed
I've been using btrfs for a while as my /home (converted from ext4;
encrypted lvm) when it died on me. Mounting it crashes immediately,
here's a log:
[ 6.455721] [ cut here ]
[ 6.456117] kernel BUG at fs/btrfs/inode.c:4586!
[ 6.456117] invalid opcode: [#1]
This is fixed upstream, I've sent the patch to -stable so hopefully it
will show up in fedora soon, but in the meantime can you try Linus's
tree and verify that it fixes it? Thanks,
Thanks, it appears to be fixed (at least in a VM). Will try native soon.
--
To unsubscribe from this list:
On Tue, Aug 23, 2011 at 5:27 PM, Hugo Mills h...@carfax.org.uk wrote:
Could you give a bit more information about what happened in the
crash immediately prior to the FS being unmountable,
I was talking on the phone (HTC Desire running Android 2.2).
and how your
storage is configured?
On 11/15/2010 07:05 PM, Josef Bacik wrote:
Ext4 doesn't have the ability to punch holes yet, so make sure we return
EOPNOTSUPP if we try to use hole punching through fallocate. This support can
be added later. Thanks,
Instead of teaching filesystems to fail if they don't support the
On 11/16/2010 02:50 PM, Josef Bacik wrote:
On Tue, Nov 16, 2010 at 02:25:35PM +0200, Avi Kivity wrote:
On 11/15/2010 07:05 PM, Josef Bacik wrote:
Ext4 doesn't have the ability to punch holes yet, so make sure we return
EOPNOTSUPP if we try to use hole punching through fallocate
On 03/30/2010 03:56 PM, Chris Mason wrote:
On Sun, Mar 28, 2010 at 05:18:03PM +0200, Diego Calleja wrote:
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the raw
qemu format according to virt-manager and, of course, placed on a btrfs
filesystem, running the latest mainline git)
On 04/08/2010 06:26 PM, Chris Mason wrote:
Once the O_DIRECT read patch is in, you can switch to that, or tell qemu
to use a writeback cache instead.
Even with writeback qemu will issue a lot of fsyncs.
Oh, I didn't see that when I was testing, when does it fsync?
When it
On 04/08/2010 06:34 PM, Christoph Hellwig wrote:
On Thu, Apr 08, 2010 at 06:28:54PM +0300, Avi Kivity wrote:
When it updates qcow2 metadata or when the guest issues a barrier. It's
relatively new. I have a patch that introduces cache=volatile somewhere.
qcow2 does not issues any
Nick Piggin wrote:
(no they're not, Nick's ticket locks still spin on a shared cacheline
IIRC -- the MCS locks mentioned could fix this)
It reminds me. I wrote a basic variation of MCS spinlocks a while back. And
converted dcache lock to use it, which showed large dbench improvements on
a
Peter Zijlstra wrote:
Subject: mutex: implement adaptive spinning
From: Peter Zijlstra a.p.zijls...@chello.nl
Date: Mon Jan 12 14:01:47 CET 2009
Change mutex contention behaviour such that it will sometimes busy wait on
acquisition - moving its behaviour closer to that of spinlocks.
This
Peter Zijlstra wrote:
On Mon, 2009-01-12 at 18:13 +0200, Avi Kivity wrote:
One thing that worries me here is that the spinners will spin on a
memory location in struct mutex, which means that the cacheline holding
the mutex (which is likely to be under write activity from the owner
Peter Zijlstra wrote:
Spinlocks can use 'pure' MCS locks.
How about this, then. In mutex_lock(), keep wait_lock locked and only
release it when scheduling out. Waiter spinning naturally follows. If
spinlocks are cache friendly (are they today?) we inherit that. If
there is no
Stephan von Krawczynski wrote:
- filesystem autodetects, isolates, and (possibly) repairs errors
- online scan, check, repair filesystem tool initiated by admin
- Reliability so high that they never run that check-and-fix tool
That is _wrong_ (to a certain extent). You _want to
jim owens wrote:
Avi Kivity wrote:
jim owens wrote:
Remember that the device bandwidth is the limiter so even
when each host has a dedicated path to the device (as in
dual port SAS or FC), that 2nd host cuts the throughput by
more than 1/2 with uncoordinated seeks and transfers.
That's only
Ric Wheeler wrote:
One key is not to replace the drives too early - you often can recover
significant amounts of data from a drive that is on its last legs.
This can be useful even in RAID rebuilds since with today's enormous
drive capacities, you might hit a latent error during the rebuild on
Chris Mason wrote:
You want to have spare capacity, enough for one or two (or fifteen)
drives' worth of data. When a drive goes bad, you rebuild into the
spare capacity you have.
You want spare capacity that does not degrade your raid levels if you
move the data onto it. In some
Ric Wheeler wrote:
I think that the btrfs plan is still to push more complicated RAID
schemes off to MD (RAID6, etc) so this is an issue even with a JBOD.
It will be interesting to map out the possible ways to use built in
mirroring, etc vs the external RAID and actually measure the utilized
Tejun Heo wrote:
For most SATA drives, disabling write back cache seems to take high
toll on write throughput. :-(
I measured this yesterday. This is true for pure write workloads; for
mixed read/write workloads the throughput decrease is negligible.
As long as the error status is
Andi Kleen wrote:
There are some patches to do in QEMU's cow format for KVM. That's
user level only.
And thus, doesn't work for sharing between different images, especially
at runtime.
It would work if the images are all based once on a reference image, won't it?
Yes
I've been reading btrfs's on-disk format, and two things caught my eye
- attribute((packed)) structures everywhere, often with misaligned
fields. This conserves space, but can be harmful to in-memory
performance on some archs.
- le64's everywhere. This scales nicely, but wastes space. My
Chris Mason wrote:
On Fri, 2008-10-03 at 14:42 +0300, Avi Kivity wrote:
I've been reading btrfs's on-disk format, and two things caught my eye
- attribute((packed)) structures everywhere, often with misaligned
fields. This conserves space, but can be harmful to in-memory
performance
Josef Bacik wrote:
Could you try with the unstable git tree? I just rewrote a bunch of this stuff
and like to know if the same issue is present there. I wouldn't recommend using
unstable for your home directory yet tho, that code still may eat children.
Thanks,
Will try that on a virtual
39 matches
Mail list logo
