| 1 |
On Fri, May 15, 2015 at 2:32 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
> The new item doesn't really cover this much -- that the feature is for |
| 4 |
> supporting storage and synchronization of the gentoo repo on squashfs |
| 5 |
> rather than on a regular filesystem. Perhaps it would be enough to |
| 6 |
> link to an article describing the benefits of using a squashfs'ed |
| 7 |
> portage tree, so users could chose whether they want this or not based |
| 8 |
> on that? Similarly, it would probably be good to mention that this |
| 9 |
> new feature deprecates squash_portage and the other tools/methods out |
| 10 |
> there for doing the same thing locally. |
| 11 |
> |
| 12 |
|
| 13 |
That makes sense to me. Some of the likely benefits would be: |
| 14 |
|
| 15 |
1. Less disk space use. |
| 16 |
2. Vastly less inode use. |
| 17 |
3. Much less CPU/IO to update. |
| 18 |
4. I suspect much less fragmentation/write/etc for storage on flash. |
| 19 |
Then again, on filesystems like btrfs fragmentation might be worse due |
| 20 |
to all the internal writes. |
| 21 |
5. Probably better read performance (less disk IO, more CPU). |
| 22 |
|
| 23 |
Downsides include: |
| 24 |
1. No way to sync more frequently than whatever the update cycle is. |
| 25 |
It would be more like emerge-webrsync and less like emerge --sync. |
| 26 |
2. Impossible to tweak ebuilds without setting up an overlay. This |
| 27 |
might be annoying for devs/etc. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives