On 22/11/18 at 19:21, Roger Leigh wrote: > On 21/11/2018 16:11, Alessandro Selli wrote: >> On 21/11/18 at 13:17, Roger Leigh wrote: >>> Hi folks, >>> >>> I've been following the discussion with interest. >> >> >> No, you definitely have not followed it. In fact you are >> disregarding >> all the points that were expressed against the merge. > > Let me begin by stating that I found your reply (and others) to be > rude, unnecessarily aggressive, and lacking in well-reasoned objective > argument.
Oh poor show flake, did I hurt your tender feelings when I state facts? [...] Again I express something so simple I'm really beginning to lose my mind: I do not intend to deprive anyone with the freedom to merge /usr to /, damn it! I want to preserve *MY* freedom of choice, I want to be able to split from / anything that is not required on *MY* systems or that will never be required on any system (Java, Apache, Squid, Xorg, LibreOffice etc). I am not fighting against people who want to introduce different filesystem layouts because of their special needs, I WANT THEM TO STOP FORCING THEIR DESIGN CHANGES TO ME FOR NO OTHER REASON THAT TO THEIR SYSTEMS THEIR LAYOUT MAKES MORE SENSE! Is it clear enough now? I hope so. >> 1) mounting /usr with different mount options (like barrier, ro, >> nodev etc); > > Could you describe the specific goals of the separation? Damn it, again? Re-read the thread yourself, it's going to take you less time than it must have taken writing 58 lines, 1458 words and 8565 characters of text to justify the necessity of a / -> /usr merge. [...] > think about the specific problems which you are really trying to > solve, rather than tying the solution to this specific mountpoint. What? Did you read the Subject line at least? All this discussion is centered on "this specific mountpoint"! > Most of / should be ro+nodev just like for /usr. Yeah. Only, / can't be, but /usr can be. > So one deeper question is which bits of / shouldn't be ro/nodev? > /etc? /var? Everything except /dev, of course. > Maybe it should be between / and /etc and /var? Others? Are you kidding? How could you split /etc and /var from /? Are you really saying that keeping /usr split from / makes no sense because you can't split /var and /etc from /? > I should point out that I wrote a set of patches for mounting /etc in > the initramfs as well as /usr, specifically so that you could do this. First you stated that having a separate /usr is to be avoided because it's too troublesome and unmanageable, now you say you split even /etc from /? Great! I'm overjoyed! Since you could do something even more difficult, that no Unix system did before TIKO, could I ask you to please do me a favour? Will you keep /usr splittable from /, as it's been the case for decades even before Linux existed? >> 2) having /usr mounted over the network keeping / local; > While the initramfs does support both local / and remote /usr (by *my > own design and intent*), this is purely to avoid breakage on upgrades. > It's not a recommended setup. What does not "recommended" entail? Is moving /home to /var/Drake/shared recommended? I don't think so. Should this be made impossible then? And is so why? > All the cluster nodes Here we have it again: the changes that are being pushed have clusters as their reference system. But I mostly use GNU/Linux as a desktop system. If Debian is going to follow the Red Hat path, that is design their system tailored just for the Big Data Centers (BDC) needs precluding most desktop customizations, fine, it's their right. I will stay clear of it and will chose other distros that have commoners and their laptops as the typical target. > The content of that /usr filesystem is under the control of *one* dpkg > package database on a single system. If *any* of the other systems > install or remove any package touching /usr (which is all of them!), > they will be corrupting the installation. This only has sense for cluster installs, not desktop ones. If what you're writing means: "Debian from now on will only cater to the needs of BDCs, local desktop customizations will be ignored" well, I'm fine with it. I'll just not go back to Debian, as I do not run a BDC home or on my portable devices. Anyway, syncing updates of shared filesystems can be done with shared mounts. I thought to do some experiments with it some time ago, but then didn't. The relevant documentation is in Documentation/filesystems/sharedsubtree.txt . It should be enough to do this: # mount --make-shared / # mount nfs_server:/storage/shared_root /mnt/root # mount --bind / /mnt/root # mount /dev/sda5 /usr If I am correct, now both / and /usr should be visible under /mnt/root. This way a local update should be propagated to the NFS filesystem. > Even mounting it read-only is giving you an incomplete view of the > installed packages' contents. Why is that? Did I already state that ro is not the only mount option that makes sense to have different between the /usr and the / filesystems? > This is not a sensible or robust strategy I beg to differ, as it's been done for decades. It might not make sense *on* *a* *cluster*, but allow me not to care about the corporate datacenter needs, they are not mine own. Even if I were a datacenter sysadmin, I didn't want to manage my laptop the same way I manage the big iron. And I want to preserve my liberty to choose the way I can customize my laptop regardless of what does not make sense to the datacenter. >> 4) having the smallest possible / filesystem to ease recovery of a >> botched system. > I'd personally go for a dedicated rescue disk/USB stick/live CD for > this specific purpose. Personal choice is just that, a personal choice, nothing technically compelling. I do use "rescue disk/USB stick/live CD" to do system recovery, and I figured out that it still makes sense recover 4GiB of filesystem data instead of 10, especially with slow devices like USB sticks and DVDs (and I can't put 10GiB of data on DVDs): [alessandro@wkstn02 ~]$ df / /usr Filesystem Size Used Avail Use% Mounted on /dev/mapper/pt4_crypt 9,8G 4,3G 5,0G 47% / /dev/mapper/pt5_crypt 9,8G 6,2G 3,1G 68% /usr [alessandro@wkstn02 ~]$ On one systems I no longer run I installed two / filesytems, first they were independent and were put in sync periodically, then I make them mirrors. But they shared the same /usr (and /home). /usr and /home were regularly backupped, / was not. On a laptop (that too I no longer have) I had two /s that were meant to stay separate. One I booted from when I held classes, the second I used for all other uses. They were devised to keep different configuration concerning users and servers according to the different circumstances, after i got fed up scripting the reconfiguration of many services and system settings for the different scenarios. With a merged / and /usr all of these things would be more difficult or would require more time and stuff (larger USB sticks, separate external backup disks, full separate installations of system virtualization and so forth). > If you can emergency boot a current system with a separate /usr, that > is a lucky happenstance. I did it dozens of times. In fact I do it expressly in my system recovery classes: "Now let's see what happens if in /etc/fstab the /usr line is commented out and I reboot!". Which is an easy way of simulating a major filesystem corruption. > I hope that the explanations I've given above give you just a little > bit of insight into some of the problems for which I have thought > quite deeply upon over the course of several years, and spent > significant time investigating, implementing and testing. All you wrote boils down to: "We're designing Debian for the Data Center. Like it or leave it". Well, I leave it. Bye, -- Alessandro Selli <[email protected]> VOIP SIP: [email protected] Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
