On 01/03/2011 06:35 PM, Eric Sandeen wrote:
On 12/27/2010 03:41 AM, Avi Kivity wrote: > If Anaconda has just formatted a volume, we know that there is no data > on that volume that can be lost. We can therefore mount it, for the > duration of the installation, with barriers disabled (and make other > tradeoffs in the performance/integrity equation, like using > data=writeback for ext4). > > The installed image should enable barriers as usual. > > The result would be faster installation, and thus a better user experience. If we have just formatted it, this is probably ok; I assume that a power loss or crash during install would always result in a reinstall.
Yes. No data can be lost.
Do you have any benchmarks of an install with/without barriers?
No, but there are a lot of requests for kvm to run installs with barriers disabled (on the host side, that is not issue fsync()s in response to guest flushes) during installation. I consider my suggestion better since it works for non-virtualized installs, and removes the need for the management system to know when an install takes place, and when it ends (on the other hand, it will only work for installs of guests with the updated installer).
It'd be worth testing it on a rawhide compose (do we do that still?) because the whole barrier infrastructure has changed a lot upstream, recently. I'm a little less excited about other random tweaks for filesystems such as data=writeback, since this means the installer will be using codepaths that we don't recommend or support or test. But it'd be interesting to see some install perf numbers for a given kickstart file, I suppose, and for different install scenarios (ssd, sata, virt, etc).
Sure. I imagine we'll see measurable benefit since installs are metadata intensive.
-- error compiling committee.c: too many arguments to function _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
