Eric Sandeen wrote:
Jan Kara wrote:
In looking at what we have today, I wonder if we can make things smarter
so that we don't commit empty transactions in any case?
Probably it does not make sence to commit such transactions and we might
save some time in sync paths if we do so. So yes, I think skipping empty
transaction commit might be worthwhile and it shouldn't be hard to do
either. But I'd give it serious testing just in case some unexpectedly
relies on this behaviour - wouldn't this interfere e.g. with sync
transaction batching autotuning code? Untested patch below...
Honza
Cool, thanks! This's stop:
# sync
from spinning up disks under idle filesystems too, I think.
I was looking at something similar but was still working out how many
things to check before deciding if the transaction was in fact empty. :)
-Eric
Without having dived into the patch in detail, one worry I would have is
that we still might care to spin up a drive for empty transactions in
order to invalidate the drive's write cache.
For example, if we have the following sequence:
(1) user app performs series of writes to file A
(2) pages dirtied from writes to A are destaged to the disk over time
(3) user app issues fsync(file A) to make sure that the data will
survive a power outage
At this point in time, would this change prevent us from spinning up the
drive and invalidating the disk write cache for that fsync() ?
Regards,
Ric
--
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
