On Wed, Jan 7, 2015 at 12:26 PM, Neil Bothwick <[email protected]> wrote: > On Wed, 7 Jan 2015 16:12:28 +0000 (UTC), James wrote: > >> > That's why I thought XFS may help. >> > Reports of the speed gain from tmpfs are quite mixed, but I do use it >> > myself. >> >> I'm moving to btrfs and eventually ceph, so xfs is not on my roadmap.... > > Not as a general FS, but as a specific choice for $PORTAGE_TMPDIR it may > be worth testing. XFS was designed for an environment that used temporary > files that didn't need to be committed to disk, so its caching doesn't > write to disk anywhere near as often. That means you would be working > with files stored in RAM a lot of the time. >
If you're going to be saving the build files using mv/ln (or with cp --reflink on a filesystem that supports this), then the LAST thing I would do is use a different fs for PORTAGE_TMPDIR. The best-performing option would be to make it a directory on the same filesystem as wherever you're going to store the files by moving/(ref)linking them. That makes the move/(ref)link operation require minimal IO. If you put PORTAGE_TMPDIR on xfs, and then mv all those files to a separate filesystem, then you're going to have to do a disk-to-disk copy of everything and a removal of the original files. That is expensive in terms of IO. At last with a tmpfs you're just doing memory-to-disk so you're only doing disk IO once. If you're going to create tarballs then tmpfs will still be fastest, but using another filesystem for PORTAGE_TMPDIR isn't a problem since you're going to have to do disk-to-disk IO no matter what, since creating a tarball will always require rewriting everything. -- Rich
