Re: Rename BTRfs to MuchSlowerFS ?

[Roman Mamedov <rm@romanrm.ru>]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Mon, 5 Sep 2011 15:00:23 +0100
Hugo Mills <hugo@carfax.org.uk> wrote:
> > 
> > BTRFS machine took 20 HOURS so far, still counting (ETA 15 minutes left).
> > 
> > Wow. Impressive.
> 
>    That's because dpkg is known for using (f)sync very heavily.  btrfs
> honours the sync request in all cases

I don't think it's *just* that.

I had the same problem, recently upgrading Debian from Stable to Testing, it was taking more than 24 hours. I stopped the upgrade, then resumed it this time via eatmydata, and it proceeded perhaps two orders of magnitude faster than before, finishing the remaining packages in 5 minutes or so.

Problem is, even when I stopped the upgrade and waited a considerable time, each 'sync' was still taking 5-7 seconds. No other disk activity in the system, no snapshot creation/deletion/cleanup going on either, just multiple consecutive syncs:

rm@rm:~$ time sync

real	0m4.772s
user	0m0.000s
sys	0m0.480s
rm@rm:~$ time sync

real	0m6.831s
user	0m0.000s
sys	0m0.472s
rm@rm:~$ time sync

real	0m8.069s
user	0m0.000s
sys	0m0.468s
rm@rm:~$ time sync

real	0m6.675s
user	0m0.000s
sys	0m0.464s
rm@rm:~$ time sync

real	0m4.293s
user	0m0.000s
sys	0m0.464s
rm@rm:~$ time sync

real	0m4.230s
user	0m0.000s
sys	0m0.472s
rm@rm:~$ time sync

real	0m6.924s
user	0m0.000s
sys	0m0.464s

To be fair, this was on the 2.6.39.2 kernel, and the performance seems to be somewhat better on 3.0 (though I didn't do tests like this one or any significant dpkg operations on it yet).

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]