Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 09:11:05PM +0200, Bernd Zeimetz wrote: Marco d'Itri wrote: On May 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: - NFS This is not detailed. - for my wifi box (ie a 386 SX with 8MB of flash) This is not real world. It is. Not with Debian it isn't. Debian hasn't worked on true-386 systems for several releases. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Hi, On Dienstag, 5. Mai 2009, Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). besides that appearantly Ubuntu keeps supporting /usr, it's pointless to discuss this here. LSB which maintains FHS is the right place for this. On Dienstag, 5. Mai 2009, Marco d'Itri wrote: Could you elaborate on the kind of large changes there are in Debian to support this? I'd rather not change subject. And this is just hillarious. If you can't explain why, why bother? regards, Holger signature.asc Description: This is a digitally signed message part.
Re: deprecating /usr as a standalone filesystem?
On Tue May 05 20:07, Iustin Pop wrote: Scenarion A, desktop - / on non-LVM, fixed size, as recovery from a broken LVM setup is way harder if / is on LVM - /usr on LVM, as it can grow significantly, and having it on LVM is much more flexible This is what I do on all of my machines -- Matthew Johnson signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 06:49:47PM +0200, Josselin Mouette wrote: Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit : That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? Of course, you just need to think the image you actually update as a master image, after which it is replicated by any means necessary (be it systemimager or NFS). Sure, but you effectively only have one master image. You don't have multiple users of /usr with differing /etc or /var. They are all kept in sync. This kind of makes /usr redundant since it is sharable but only among identical systems or else you will run into problems. As for NFS, I’d use root NFS instead of complicating my life with two different methods for / and /usr, but I guess some are doing it this way. On the compute cluster I helped set up for biological modelling, we opted to use Debian Live images on the cluster. It IIRC NFS mounts a read-only cramfs filesystem and uses aufs on top of that. There's just the one big filesystem (plus some site-specific mounts for shared data and a big scratch area all the nodes can access). We certainly saw no point in making just /usr mountable since you need a matching rootfs to accompany it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 06:50:47PM +0200, Giacomo Catenazzi wrote: Roger Leigh wrote: On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote: Marco d'Itri a écrit : I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? So why we created /usr/share (and moved documentation) ? Good question. While it's nice to keep arch-indep and arch-dep files separated, I have never seen any cases where the arch-indep information is actually shared amongst architectures (except for at the arch:all package level, of course). But also I don't think it is a problem sharing usr on multiple system with multiple configurations. Keeping such as configuration updated would be hard, since each system would have an independent dpkg state in /var and different conffile state in /etc. If you removed a package on one system, it might purge files in use on another, and if you install a package on one the conffiles won't be installed on the others, etc.. On non public working stations, one doesn't run randomly programs. If I installed mysql-server on a system, it will work on such system, but if I install on an other system, it work also on the other system, occupying only one instance. I don't see problem from package management (also because we have a nullpotent dpkg), so we can upgrade from multiple system without problems. I'm not sure I see how this would work; I'd like to see some examples, especially WRT the simple problems I outlined above. Looking at GNU/Hurd, /usr is a symlink to /. If we were to make /usr non-separable, maybe this would be the way to go. or plan9, which bind mount all /*/bin into the main /bin. I can live with such solution, but please allow us to use /usr in a different (maybe shared) partition. The plan9 situation is truly wonderful, and one can only hope that Linux can do this at some point in the future. I know we have unionfs and aufs, but I wouldn't trust them for this just yet! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote: So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - it's really useful on my 386 SX with a 40 MB hard disk How about a 486 with a 96 MB Disk-on-Chip module? I maintain one such computer (it's a PC104 form factor machine), as well as a number of AMD Geodes (586) with 256 MB CompactFlash cards. It is very useful for these sytems to have a minimal and functioning root filesystem, but to mount /usr over NFS. Also, thin clients without harddisks may have a small SSD or get an initrd with a root filesystem from TFTP, but again mount a shared, possible read-only /usr over NFS. I have an EeePC 901 with root and /home on the first 4 GB SSD, and /usr on the second 16 GB SSD. The /usr is mounted read-only, and only remounted read-write when apt is running. I have this setup because the first SSD is slightly faster than the second, and the large /usr disk allows me to have a very large fraction of Debian installed. That said, the choice to put a program in /bin or /usr/bin is quite arbitrary. It would be nice if one could tell dpkg where to install a package (and its dependencies) to. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem? [386 support]
On Tue, 2009-05-05 at 17:41 +0200, Bastien ROUCARIES wrote: On Tue, May 5, 2009 at 5:36 PM, Marco d'Itri m...@linux.it wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk - NFS - for my wifi box (ie a 386 SX with 8MB of flash) Interesting. I thought 386 wasn't supported anymore (?) http://www.debian.org/releases/stable/i386/ch02s01.html.en#id2756691 Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On 11741 March 1977, Marco d'Itri wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. You havent presented any supporting your request, so why do you want it? Please provide a detailed real-world case. A partial list of invalid reasons is: - Some upstream wont fix his software to be FHS compatible -- bye, Joerg Five exclamation marks, the sure sign of an insane mind. -- Terry Pratchett, Reaper Man -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote:
So, does anybody still see reasons to continue supporting a standalone
/usr?
There had been lots of responses to that.
Yes, the most repeated argument has been mount /usr via NFS.
Unfortunately, nobody yet explained how do they update the resulting
cluster of machines.
Of course the problem is that if you update on the NFS server, then
related /etc and /var files [1] will not get updated on the NFS client
machines and you need to propagate changes there. I see as quite
pointless to use let's export /usr via NFS as an argument, if Debian
does not provide a way to make that setup tenable.
ACK on your second clarification request, though.
Cheers.
[1] Or anything else actually, given that maintainer scripts can
affect basically all the filesystem.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Well, some people argued for that. Like you, I'm wondering how one actually does this in practice! However there are some rather more reasonable uses which have been mentioned: - read-only /usr (for security) - backups - recovery (ability to mount root only; important if there's fs corruption) - on-line resizing - using LVM and/or RAID (Note: With modern Debian initramfs it is quite possible to have / on LVM [on RAID] since so long as /boot lives outside the initramfs can bring up RAID and initialise LVM to mount the rootfs. The system I'm physically typing this on has such a setup.) /dev/mapper/ravenclaw-root on / type ext3 (rw,relatime,errors=remount-ro) /dev/sda2 on /boot type ext2 (rw,nodev) /dev/mapper/ravenclaw-home on /home type ext3 (rw,nosuid,nodev,usrquota,grpquota,user_xattr) /dev/mapper/ravenclaw-usr on /usr type ext3 (rw,nodev,relatime) /dev/mapper/ravenclaw-var on /var type ext3 (rw,nodev,user_xattr) tmpfs on /tmp type tmpfs (rw,size=6G,mode=1777) /dev/mapper/ravenclaw-chroots on /srv/chroot type ext3 (rw) /dev/mapper/ravenclaw-mybook--backup on /srv/data/phd type ext4 (rw,nosuid,nodev,user_xattr) tmpfs on /dev type tmpfs (rw,size=10M,mode=0755) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) I certainly think that there's continued need for a separable /usr at the present. I'm intrigued as to what Marco's upstream is actually doing! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli z...@debian.org writes: Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. If you don't want to take downtime, you have two chroots on the NFS server and pivot systems back and forth between the two chroots as you do updates. People did and still do this all the time with AFS. It's pretty well-established how to make it work. I personally don't care any more because hard drives have gotten a lot bigger, but it's technically quite feasible. I see as quite pointless to use let's export /usr via NFS as an argument, if Debian does not provide a way to make that setup tenable. Certainly looks tenable right now to me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
