Re: RFE: mount newly formatted volumes with barrier=0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux