| 1 |
I have no idea who wrote this: |
| 2 |
|
| 3 |
"The historical justification for a /bin, /sbin and /lib separate from |
| 4 |
/usr no longer applies today." but I strongly disagree. |
| 5 |
|
| 6 |
Again, if /usr goes belly up (which with recent ext4/io bug(s) we've had |
| 7 |
probably about 10 systems already that needed repairing, and at least 5 |
| 8 |
more that's pending), this fault would require me to head out to site to |
| 9 |
go and repair where currently due to fsck et al living on / and not on |
| 10 |
/usr I could recover without issues. |
| 11 |
|
| 12 |
We've been unable to track an exact issue, but all of the affected |
| 13 |
systems was running 4.14.X kernels, we've not seen the same corruption |
| 14 |
from 5.0.2 onwards. So we never filed a bug and simply upgraded kernels. |
| 15 |
|
| 16 |
Further, none of the arguments for merging / and /usr makes any sense |
| 17 |
other than "others have already done this and if we don't follow suite |
| 18 |
we'll get cut off". Not even the statement about network share of /usr |
| 19 |
makes any sense. We run completely diskless systems with even / over |
| 20 |
nfs ... so seriously. |
| 21 |
|
| 22 |
Even most of the myths and facts arguments are plainly uneducated. |
| 23 |
|
| 24 |
Essentially what happens now is that an initrd needs to be built to |
| 25 |
contain ALL recovery tools that could possibly be required. Where |
| 26 |
previously, with / being mostly read-only this was still a risk worth |
| 27 |
taking. |
| 28 |
|
| 29 |
Anyway, from the looks of this, this is just another comply or die |
| 30 |
situation, so I'm not seeing that there is much choice or say in this |
| 31 |
matter. We'll just have to bloat our initrd's even further. |
| 32 |
Fortunately they do get freed post post ... just hoping they'll fit into |
| 33 |
the existing /boot partitions we have on our systems. |
| 34 |
|
| 35 |
|
| 36 |
Kind Regards, |
| 37 |
Jaco Kroon |
| 38 |
C.E.O. |
| 39 |
|
| 40 |
*T:* +27 (0)12 021 0000 | *F:* +27 86 648 8561 | *E:* jaco@×××××××.za |
| 41 |
*W:* iewc.co.za <http://www.iewc.co.za/> | *A:* Unit 201, Building 2B, |
| 42 |
Sunwood Park, Queen's Crescent Lynnwood, Pretoria |
| 43 |
|
| 44 |
|
| 45 |
|
| 46 |
|
| 47 |
Facebook <https://www.facebook.com/Interexcel/> Twitter |
| 48 |
<https://twitter.com/Interexcel/> Google+ |
| 49 |
<https://plus.google.com/+InterexcelCoZaPTA/posts> LinkedIn |
| 50 |
<http://www.linkedin.com/com/images/ico-linkedin.jpg> |
| 51 |
|
| 52 |
<http://www.iewc.co.za/> <http://www.uls.co.za/> |
| 53 |
|
| 54 |
This email and all contents are subject to the following disclaimer: |
| 55 |
View Disclaimer <http://www.iewc.co.za/email-disclaimer/> |
| 56 |
|
| 57 |
On 2019/07/15 16:22, Marek Szuba wrote: |
| 58 |
> On 2019-07-15 14:59, Jaco Kroon wrote: |
| 59 |
> |
| 60 |
>> I've seen arguments that it's a historic split, and to an extent this is |
| 61 |
>> true, however, having critical system recovery (and basic boot) stuff in |
| 62 |
>> /, on as small as possible a partition, with the bulk of the system on |
| 63 |
>> /usr makes a lot of sense for me. |
| 64 |
> That's one of the reasons, yes. For a more in-depth discussion, see |
| 65 |
> |
| 66 |
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ |
| 67 |
> |
| 68 |
> as well as the Fedora feature the above mentions. |
| 69 |
> |
| 70 |
> ))/io |
Archives
