On Wed, Aug 04, 2010 at 11:26:56AM -0400, Greg Freemyer wrote: > > Since the proposed patch is not aggregating discards into multiple > ranges per ATA command, I thought some of the non-optimized devices > would take minutes / hours? > > If true, a way to control the progress from userspace is important. > > If in general it is only going to take a few seconds for a full FITRIM > to run, it is much less important, but I suppose the the RT project > might find even that problematic. Even if it without the RT project, if disk activity is slowed or completely stopped for a few seconds, I can think of plenty of workloads where this would be totally unacceptable. Suppose you are running a web site; it doesn't really matter whether it is at Google, Facebook, Twitter, etc. If this means that one or more web pages get stalled by "a few seconds" while the FITRIM is going on, this is generally not considered acceptable. Even if it slows down the server by 30-50%, for some sites this would also be quite unacceptable. This is a hard problem to solve, though, especially if there is an insistence to solve it in a fs-independent fashion. I could imagine doing this at work, by doing things one block group at a time, and then I could measure, for our specific hardware, how badly disk performance would get hit, and for how long, and then the userspace daemon could control how many block groups to do per unit time. But this would be of necessity ext2/3/4 specific.... So I'm not sure what to suggest here. Maybe the answer is we can have a fs-independent ioctl for desktop workloads, and one which gives more fine-grained control for those who need it? That seems ugly, but it might be the best compromise. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
