On Mon, 5 Sep 2011 15:00:23 +0100 Hugo Mills <hugo@xxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
