"Richard W.M. Jones" <rjones@xxxxxxxxxx> writes: >> > for each filesystem: >> > mount -o discard $fs /mnt >> >> What is $fs? Do you pass in a list of devices? > > Yes and no. We examine the partitions, logical volumes and so on in > order to get a list of mountable filesystems, and then the list is > iterated over in this loop. The precise code for finding the > filesystems is here: > > https://github.com/libguestfs/libguestfs/blob/master/src/listfs.c#L45 > > ^ That code is running on the host side. It issues various calls to > the appliance side which are executed by code in multiple files here: > > https://github.com/libguestfs/libguestfs/tree/master/daemon Sorry, that's a lot to take in. Can you distill this down to exactly the parts involved in the problem you're seeing? Pretend I don't know anything about libguestfs (I don't). >> Do you have a golden image you start with so that your test case is >> repeatable? > > We create images on the fly, but yes I'm confident that the test is > repeatable (although that doesn't mean it is failing on every run -- > it's a race condition of some sort). The test code is here: > > https://github.com/libguestfs/libguestfs/blob/master/tests/discard/test-fstrim.pl I suggest you create a golden image that you copy for each test that already has the data committed to it. The test would then just issue the rm and discard. $g->fill (33, 10000000, "/data"); What's that do? >> > It appears that when the host is slow / under load, the problem >> > happens more frequently. Also it may happen more frequently on i686 >> > than on x86-64 (possibly also due to speed of host). >> >> I don't know of any reason that any of the variables you listed would >> affect the reliability at all. As far as I can tell, fstrim is a >> synchronous ioctl. I believe the only reason space wouldn't be freed is >> if the fs is fragmented in such a way as to not meet the minimum trim >> granularity of the underlying device. > > It's a freshly created filesystem so I guess it's not likely to be > fragmented. It's only 64MB in size, right? That could certainly affect things! Again, we'd need some input from file system folks, though. I'm hoping we're getting enough information for them to make progress. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
