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.
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.
Do you have any benchmarks of an install with/without barriers?
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).
-Eric
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.
On 01/03/2011 10:47 AM, Avi Kivity wrote:
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.
Yeah, it should be a win.
Switching off barriers for a -freshly-made- filesystem is fine with me.
Just need to be 100% sure that it doesn't persist in fstab, and that we do not mount -existing- filesystems with barriers off.
-Eric
On 01/03/2011 06:56 PM, Eric Sandeen wrote:
Sure. I imagine we'll see measurable benefit since installs are metadata intensive.
Yeah, it should be a win.
Switching off barriers for a -freshly-made- filesystem is fine with me.
Just need to be 100% sure that it doesn't persist in fstab, and that we do not mount -existing- filesystems with barriers off.
I don't know the anaconda code, but I'd go for mounting normally, then issuing a 'mount -o remount,barrier=0' to disable barriers for the duration of the install.
On 01/03/2011 11:03 AM, Avi Kivity wrote:
On 01/03/2011 06:56 PM, Eric Sandeen wrote:
Sure. I imagine we'll see measurable benefit since installs are metadata intensive.
Yeah, it should be a win.
Switching off barriers for a -freshly-made- filesystem is fine with me.
Just need to be 100% sure that it doesn't persist in fstab, and that we do not mount -existing- filesystems with barriers off.
I don't know the anaconda code, but I'd go for mounting normally, then issuing a 'mount -o remount,barrier=0' to disable barriers for the duration of the install.
One other thing that will need to be added, I think, is a way to flush drive caches when it's all done. (Ric pointed this out).
Otherwise you'll have fresh data/metadata sitting in a drive cache post-install, and what happens when you reboot? How lucky do you feel? :)
We'll need to do a quick mount/unmount with barriers, or an explicit cache flush of the device via the blkdev tool, or something, to guarantee that all the install data is safely though the cache and on disk.
-Eric
anaconda-devel@lists.fedoraproject.org
-
Avi Kivity -
Eric Sandeen