On Tue, Mar 11, 2014 at 11:30:47PM +0000, Richard W.M. Jones wrote: > On Tue, Mar 11, 2014 at 06:09:28PM -0500, Eric Sandeen wrote: > > On Tue, Mar 11, 2014, Richard W.M. Jones wrote: > > > However just the act of doing the tracing *caused* the trim to happen > > > properly in the underlying disk. > > > > that sounds very strange... > > Thanks Eric. > > FYI the libguestfs / virt-sparsify patch series that motivates this is > here: > > https://www.redhat.com/archives/libguestfs/2014-March/thread.html#00091 > > Even with the greatly reduced set of traces (see attached), just the > act of tracing seems to have made trimming work properly. The output > file has been trimmed properly from 926 MB to 819 MB: I did a bit more testing on this. It appears we are sure that the ext4 ioctl FITRIM is sending discard requests. However fstrim doesn't happen reliably. fstrim + blktrace works reliably fstrim + fsync unreliable, usually fails to trim fstrim + sync unreliable, usually fails to trim fstrim + umount unreliable, usually fails to trim fstrim + sleep 10 unreliable, usually fails to trim ( fstrim + sleep 10 ) x 3 unreliable, usually fails to trim fstrim on its own unreliable, usually fails to trim Somewhere, the discard requests are disappearing in the stack (or more likely, being delayed). blktrace/trace-cmd somehow forces them out. But fsync/sync/umount/sleep does not. They might be stuck in qemu too ... Is there any further test I can try here? Is there a way to force out discard requests? qemu cache mode is set to writeback. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
Attachment:
test-fstrim.pl
Description: Perl program
