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
