qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V3] qemu-img create: add 'nocow' option


From: Chun Yan Liu
Subject: Re: [Qemu-devel] [PATCH V3] qemu-img create: add 'nocow' option
Date: Tue, 01 Jul 2014 21:03:54 -0600


>>> On 7/2/2014 at 05:02 AM, in message <address@hidden>, Eric Blake
<address@hidden> wrote: 
> On 06/23/2014 03:17 AM, Chunyan Liu wrote: 
> > Add 'nocow' option so that users could have a chance to set NOCOW flag to 
> > newly created files. It's useful on btrfs file system to enhance  
> performance. 
> >  
> > Btrfs has low performance when hosting VM images, even more when the guest 
> > in those VM are also using btrfs as file system. One way to mitigate this  
> bad 
> > performance is to turn off COW attributes on VM files. Generally, there are 
> > two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then 
> > all newly created files will be NOCOW. b) per file. Add the NOCOW file 
> > attribute. It could only be done to empty or new files. 
> >  
> > This patch tries the second way, according to the option, it could add  
> NOCOW 
> > per file. 
> >  
> > For most block drivers, since the create file step is in raw-posix.c, so we 
> > can do setting NOCOW flag ioctl in raw-posix.c only. 
> >  
> > But there are some exceptions, like block/vpc.c and block/vdi.c, they are 
> > creating file by calling qemu_open directly. For them, do the same setting 
> > NOCOW flag ioctl work in them separately. 
>  
> Design question (not a patch review): 
>  
> It looks like your patch allows one to set the NOCOW flag via ioctl when 
> requested.  But how does one learn if the flag is already set?  Can you 
> update 'qemu-img info' to show whether a file currently has the flag 
> set? 

The reliable way to check if the file is really NOCOW is 'lsattr filename'.
-o nocow=on not really means NOCOW successfully set. We didn't block
file creation even if ioctl fails (see below).
Maybe 'qemu-img info' can call 'lsattr filename' to judge if the file is NOCOW.

> Can 'qemu-img amend' be taught to set and/or clear the flag on an 
> already existing file? 

No. It's one way. A COW file can be not changed to NOCOW, vice versa.

>  
>  
> > @@ -1291,6 +1296,21 @@ static int raw_create(const char *filename, QemuOpts 
> >  
> *opts, Error **errp) 
> >          result = -errno; 
> >          error_setg_errno(errp, -result, "Could not create file"); 
> >      } else { 
> > +        if (nocow) { 
> > +#ifdef __linux__ 
> > +            /* Set NOCOW flag to solve performance issue on fs like btrfs. 
> > +             * This is an optimisation. The FS_IOC_SETFLAGS ioctl return  
> value 
> > +             * will be ignored since any failure of this operation should  
> not 
> > +             * block the left work. 
> > +             */ 
> > +            int attr; 
> > +            if (ioctl(fd, FS_IOC_GETFLAGS, &attr) == 0) { 
> > +                attr |= FS_NOCOW_FL; 
> > +                ioctl(fd, FS_IOC_SETFLAGS, &attr); 
> > +            } 
> > +#endif 
> > +        } 
>  
> This silently ignores the nocow flag on non-Linux.  Wouldn't it be 
> better to reject the option as unsupported? 

First, other file systems (at least ext3 ext4 as I checked ) not supporting that
ioctl would simply return 0.  So we couldn't rely on the ioctl return value
to check if the option is unsupported.
 
> What happens if the ioctl fails?  Would it be better to fail the 
> qemu-img creation if the flag is requested but can't be honored? 
>  

NOCOW is an optimization for performance, we don't want it to block the file
creation. In other words, if ioctl fails, we still hope the file image is 
created.

Another reason for doing this is the ioctl return value is not consistent in
different file systems, ioctl return value:
0: not always means SUCCESS, could be UNSUPPORTED 
!0: could be supported but not successfuly (like in btrfs);
     could be unsupported at all but other error. (other fs. In this case, we 
don't
      want to block the file creation.)

>  
> > +++ b/qemu-doc.texi 
> > @@ -589,6 +589,22 @@ check -r all} is required, which may take some time. 
> >   
> >  This option can only be enabled if @code{compat=1.1} is specified. 
> >   
> > address@hidden nocow 
> > +If this option is set to @code{on}, it will trun off COW of the file. It's 
> >  
> only 
>  
> s/trun/turn/ 
>  
> > +valid on btrfs, no effect on other file systems. 
>  
> This sort of statement may get stale, if other file systems learn to 
> honor the same ioctl as btrfs. 

Yes. Currently only btrfs supports this ioctl. Writting here because we didn't
check what current fs is, and we didn't have a reliable way to report the ioctl
is unsupported (as above). So to warn users in manpage.

>  
> > + 
> > +Btrfs has low performance when hosting a VM image file, even more when the 
> >  
> guest 
> > +on the VM also using btrfs as file system. Turning off COW is a way to  
> mitigate 
> > +this bad performance. Generally there are two ways to turn off COW on  
> btrfs: 
> > +a) Disable it by mounting with nodatacow, then all newly created files  
> will be 
> > +NOCOW. b) For an empty file, add the NOCOW file attribute. That's what  
> this option 
> > +does. 
> > + 
> > +Note: this option is only valid to new or empty files. If there is an  
> existing 
> > +file which is COW and has data blocks already, it couldn't be changed to  
> NOCOW 
> > +by setting @code{nocow=on}. One can issue @code{lsattr filename} to check  
> if 
> > +the NOCOW flag is set or not (Capitabl 'C' is NOCOW flag). 
>  
> s/Capitabl/Capital/ 
>  
> Oh, so it looks like setting the attribute is one-way, and can't be 
> undone once something is written?  Or is it that it can only be set on 
> an empty file, but can be cleared at any time? 

Yes, it's one-way. A COW file can be not changed to NOCOW, vice versa.
To change, one can create a new file with expected COW or NOCOW, and
copy data to that new file.

-Chunyan

>  
> Again, making people refer to lsattr to learn if the flag is already set 
> seems painful; can qemu-img info be taught to expose this information, 
> so that one tool is sufficient to manage the entire experience? 
>  
> > +++ b/qemu-img.texi 
> > @@ -474,6 +474,22 @@ check -r all} is required, which may take some time. 
> >   
> >  This option can only be enabled if @code{compat=1.1} is specified. 
> >   
> > address@hidden nocow 
> > +If this option is set to @code{on}, it will trun off COW of the file. It's 
> >  
> only 
>  
> s/trun/turn/ 
>  
> > +valid on btrfs, no effect on other file systems. 
> > + 
> > +Btrfs has low performance when hosting a VM image file, even more when the 
> >  
> guest 
> > +on the VM also using btrfs as file system. Turning off COW is a way to  
> mitigate 
> > +this bad performance. Generally there are two ways to turn off COW on  
> btrfs: 
> > +a) Disable it by mounting with nodatacow, then all newly created files  
> will be 
> > +NOCOW. b) For an empty file, add the NOCOW file attribute. That's what  
> this option 
> > +does. 
> > + 
> > +Note: this option is only valid to new or empty files. If there is an  
> existing 
> > +file which is COW and has data blocks already, it couldn't be changed to  
> NOCOW 
> > +by setting @code{nocow=on}. One can issue @code{lsattr filename} to check  
> if 
> > +the NOCOW flag is set or not (Capitabl 'C' is NOCOW flag). 
>  
> s/Capitabl/Capital/ 
>  
> --  
> Eric Blake   eblake redhat com    +1-919-301-3266 
> Libvirt virtualization library http://libvirt.org 
>  
>  




reply via email to

[Prev in Thread] Current Thread [Next in Thread]