[Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive

[Alexander Graf]

Anthony Liguori wrote:
> On 05/17/2010 08:17 AM, Alexander Graf wrote:
>> On 17.05.2010, at 15:09, Anthony Liguori wrote:
>>
>>   
>>> On 05/17/2010 08:02 AM, Alexander Graf wrote:
>>>     
>>>>> My concern is that ext3 exaggerates the cost of fsync() which will
>>>>> result in diminishing value over time for this feature as people
>>>>> move to ext4/btrfs.
>>>>>
>>>>>          
>>>> There will be ext3 file systems for years out. Just because people
>>>> can use better and faster file systems doesn't mean they do. And
>>>> I'm sure they can't always choose. If anything, I can try and see
>>>> what the numbers look like for xfs.
>>>>
>>>>        
>>> But ext3 with barrier=1 is pretty uncommon in practice.  Another
>>> data point would be an ext3 host file system with barrier=0.
>>>      
>> Who defines what is common and what not? To me, the SLES11 default is
>> common. In fact, the numbers in the referred mail were done on an
>> 11.1 system.
>>    
>
> But it wasn't the SLES10 default so there's a smaller window of
> systems that are going to be configured this way.  But this is
> orthogonal to the main point.  Let's quantify how important this
> detail is before we discuss the affected user base.

Alright. I took my Netbook (2GB of RAM) and a USB hard disk, so I can
easily remount the data fs the vmdk image is on. Here are the results:

# mkfs.ext3 /dev/sdc1
# mount /dev/sdc1 /mnt -obarrier=1

cache=writeback

real    0m52.801s
user    0m16.065s
sys     0m6.688s

cache=volatile

real    0m47.876s
user    0m15.921s
sys     0m6.548s

# mount /dev/sdc1 /mnt -obarrier=0

cache=writeback

real    0m53.588s
user    0m15.901s
sys     0m6.576s

cache=volatile

real    0m48.715s
user    0m16.581s
sys     0m5.856s

I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.


Alex