| 1 |
On Wed, 7 Jan 2015 14:25:52 -0500, Rich Freeman wrote: |
| 2 |
|
| 3 |
> > Not as a general FS, but as a specific choice for $PORTAGE_TMPDIR it |
| 4 |
> > may be worth testing. XFS was designed for an environment that used |
| 5 |
> > temporary files that didn't need to be committed to disk, so its |
| 6 |
> > caching doesn't write to disk anywhere near as often. That means you |
| 7 |
> > would be working with files stored in RAM a lot of the time. |
| 8 |
> > |
| 9 |
> |
| 10 |
> If you're going to be saving the build files using mv/ln (or with cp |
| 11 |
> --reflink on a filesystem that supports this), then the LAST thing I |
| 12 |
> would do is use a different fs for PORTAGE_TMPDIR. The |
| 13 |
> best-performing option would be to make it a directory on the same |
| 14 |
> filesystem as wherever you're going to store the files by |
| 15 |
> moving/(ref)linking them. That makes the move/(ref)link operation |
| 16 |
> require minimal IO. |
| 17 |
|
| 18 |
That's not what I meant, but I see your point about using --reflink if |
| 19 |
making copies. My thought was to forget the whole tmpfs and copying |
| 20 |
think, set KEEP WORK in FEATURES and use XFS for PORTAGE_TMPDIR. That way |
| 21 |
most of the work is taking place in the cache without the frequent disk |
| 22 |
writes of other filesystems. I would expect XFS to be faster for this |
| 23 |
job, but have no data to support that assumption. |
| 24 |
|
| 25 |
Or you could just put TMPDIR on btrfs and snapshot after each emerge. |
| 26 |
|
| 27 |
|
| 28 |
-- |
| 29 |
Neil Bothwick |
| 30 |
|
| 31 |
Am I ignorant or apathetic? I don't know and don't care! |
Archives