Am Freitag, 16. Dezember 2011 schrieb Goffredo Baroncelli: > On Friday, 16 December, 2011 18:54:46 you wrote: > > Am Freitag, 16. Dezember 2011 schrieb Martin Steigerwald: > > > Its not critical for me to fix these issues (soon), but I am > > > curious whether its possible to get the filesystem speedier by > > > some maintenance. > > > > Maybe after it is clear why it is so slow in the first place ;). > > I had the same experience. apt-get upgrade was a frustrating > experience! > > IIRC the copy-on-write file-system in order to have good performance > have to merge the write requests most as possible. > > Instead apt-get makes a lot of sync calls which don't allow btrfs to > merge the write requests. This explains why btrfs is slow in this > case. Ah, I see. AFAIR there have been added an option for apt/aptitude to omit the fsync itself. Hmmm, a co-worker had the issue of Iceweasel with lots of tabs open being slow and I suspected that high fsync() usage of SQLite3 databases for bookmarks and stuff might be the culprit. The issue went away for him after switching to Ext4. > I found a solution, but requires a bit of setup. > > The idea is to avoid do perform sync during the package installation. > In order to avoid data loss in case of failure, I create a snapshot > before the upgrading. If something goes wrong (i.e. a power failure) I > rebooot the system from the snapshot. If the installation finish > without problem, I flush all the data to the disk and remove the > snapshot. > > For the detail, see a my old post titled "[RFC] aptitude & BTRFS slow" > (2011-10-19) Sounds more like a workaround to me than a solution. I feel reluctant about working around what seems to be a filesystem limitation. (A filesystem should not break, i.e. slow down an existing user space application beyond a certain limit I think). I wonder whether it might be a good idea to have nodatacow for /: nodatacow - Do not copy-on-write data. datacow is used to ensure the user either has access to the old version of a file, or to the newer version of the file. datacow makes sure we never have partially updated files written to disk. nodatacow gives slight performance boost by directly overwriting data (like ext[234]), at the expense of potentially getting partially updated files on system failures. Performance gain is usually < 5% unless the workload is random writes to large database files, where the difference can become very large (see https://btrfs.wiki.kernel.org/articles/g/e/t/Getting_started.html) Then writing of files would be back to the Ext3/4 way of doing it. What do you think? PS: I am not sure whether its just aptitude. I have occassional audio stalls even while not upgrading the system. But then that might be pulseaudio although sound playback threads are running with realtime priority. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
