search for: writebacks

On Tue, Jul 03, 2012 at 03:19:37PM +0200, Paolo Bonzini wrote: > This patch adds support for the new VIRTIO_BLK_F_CONFIG_WCE feature, > which exposes the cache mode in the configuration space and lets the > driver modify it. The cache mode is exposed via sysfs. > > Even if the host does not support the new feature, the cache mode is > visible (thanks to the existing

On Tue, Jul 03, 2012 at 03:19:37PM +0200, Paolo Bonzini wrote: > This patch adds support for the new VIRTIO_BLK_F_CONFIG_WCE feature, > which exposes the cache mode in the configuration space and lets the > driver modify it. The cache mode is exposed via sysfs. > > Even if the host does not support the new feature, the cache mode is > visible (thanks to the existing

writeback_inodes_sb(_nr)_if_idle() is re-implemented by replacing down_read() with down_read_trylock() because - If ->s_umount is write locked, then the sb is not idle. That is writeback_inodes_sb(_nr)_if_idle() needn''t wait for the lock. - writeback_inodes_sb(_nr)_if_idle() grabs s_umount lock when it want to start writeback, it may bring us deadlock problem when doing umount.

Well, I had the first use of the recovery mode on the RH 8.0 install CD today on a dev system. I changed the mount option for the root partition to data=writeback to see what all the claimed speed increases are about, and the system failed to mount the partition r/w, so the resulting boot failed. After search usenet, it seems other RH folks have had this problem, possibly because it is

Latest virtio spec says the feature bit name is VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_WCE is the legacy name. virtio blk header says exactly the reverse - fix that and update driver code to match. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- I'm inclined to merge it for the current kernel - safe and avoids confusion. include/uapi/linux/virtio_blk.h | 6 +++---

Latest virtio spec says the feature bit name is VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_WCE is the legacy name. virtio blk header says exactly the reverse - fix that and update driver code to match. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- I'm inclined to merge it for the current kernel - safe and avoids confusion. include/uapi/linux/virtio_blk.h | 6 +++---

Hi list, I would like to understand if, and why, the --unsafe flag is needed when using --copy-storage-all when migrating guests which uses writeback cache mode. Background: I want to live migrate guests with writeback cache from host A to host B and these hosts only have local storage (ie: no shared storage at all). From my understanding, --unsafe should be only required when migrating

Latest virtio spec says the feature bit name is VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_WCE is the legacy name. virtio blk header says exactly the reverse - fix that and update driver code to match. Cc: Paolo Bonzini <pbonzini at redhat.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changs from v1: comments updated include/uapi/linux/virtio_blk.h | 6 +++---

Latest virtio spec says the feature bit name is VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_WCE is the legacy name. virtio blk header says exactly the reverse - fix that and update driver code to match. Cc: Paolo Bonzini <pbonzini at redhat.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changs from v1: comments updated include/uapi/linux/virtio_blk.h | 6 +++---

I'm trying to enable writeback mode for the root partition. However, adding the normal option "rootflags=data=writeback" to my grub.conf kernel line doesn't result in writeback mode (according to `dmesg`). Does anyone know of a way to enable this? -Doug -- Douglas E. Warner <dwarner at ctinetworks.com> Network Engineer CTI Networks, Inc.

Hi all, I write about libvirt inconsistent behavior when mixing io=native and cache=writeback. This post can be regarded as an extension, or clarification request, of BZ 1086704 (https://bugzilla.redhat.com/show_bug.cgi?id=1086704) On a fully upgraded CentOS6 x86-64 machine, starting a guest with io=native and cache=writeback is permitted: no errors are raised and the VM (qemu, really)

Hello, I read some threads (some of them not very recent, and perhaps not up to date) and I have not found a clear answer to these: Is it advisable to have /tmp set up with data=writeback option in general? Is it again true if we are considering a laptop? Do I have also to consider writecache of disks in this case or are they totally non related? How to check/set the state of writecache for

On Fri, Feb 17, 2017 at 02:52:06PM +0100, Gionatan Danti wrote: >Hi all, >I write about libvirt inconsistent behavior when mixing io=native and >cache=writeback. This post can be regarded as an extension, or >clarification request, of BZ 1086704 >(https://bugzilla.redhat.com/show_bug.cgi?id=1086704) > >On a fully upgraded CentOS6 x86-64 machine, starting a guest with

On Fri, Feb 17, 2017 at 12:33:28 +0100, Gionatan Danti wrote: > Hi list, > I would like to understand if, and why, the --unsafe flag is needed when > using --copy-storage-all when migrating guests which uses writeback > cache mode. > > Background: I want to live migrate guests with writeback cache from host > A to host B and these hosts only have local storage (ie: no

Hi everybody, I had a problem which you may be interested in. I set data=writeback in /etc/fstab for each of my ext3 partitions (because it complains on "mount -o remount,data=writeback" with "ext3: journal mode can't be altered on remount" or similar) and rebooted. Problem: / was mounted read-only, I couldn't remount it (because mount appends the options from fstab,

Following the announcement on lkml, I have started using ext3 on one of my servers. Since the server in question is a farily security-sensitive box, my /usr partition is mounted read only except when I remount rw to install packages. I converted this partition to run ext3 with the mount options "nodev,ro,data=writeback,defaults" figuring that when I need to install new packages etc,

Thank you for the answer. What is the main reason of allowing this inconsistency in the td file? I guess that's because of the "some" distinction between the writeback and non-writeback versions. Is there any benefit from the inconsistency by using GRP in .td file and freezing lr and pc during register allocation in writeback version? Thanks, Junbum On May 23, 2013, at 11:51 AM,

VIRTIO_BLK_F_CONFIG_WCE is important in order to achieve good performance (up to 2x, though more realistically +30-40%) in latency-bound workloads. However, it was removed by mistake together with VIRTIO_BLK_F_FLUSH. It will be restored in the next revision of the virtio 1.0 standard, so do the same in Linux. Signed-off-by: Paolo Bonzini <pbonzini at redhat.com> ---

VIRTIO_BLK_F_CONFIG_WCE is important in order to achieve good performance (up to 2x, though more realistically +30-40%) in latency-bound workloads. However, it was removed by mistake together with VIRTIO_BLK_F_FLUSH. It will be restored in the next revision of the virtio 1.0 standard, so do the same in Linux. Signed-off-by: Paolo Bonzini <pbonzini at redhat.com> ---

Hi Junbum, > I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced? They're not allocated during CodeGen because of the Reserved.set(…) calls in