On 07/04/17 08:43 PM, Marc Chamberlin wrote:
On 04/07/2017 03:45 PM, Carlos E. R. wrote:
My /usr contains 32 GB of files. Wow! I will make a big partition for future growth!
I suggest that you think about what is actually under /usr/ I have # ls /usr X11R6 bin games include lib lib64 local sbin share src tmp x86_64-suse-linux Where do you think growth will occur? * /usr/local is a separate FS. I want my locally developed items to be able to survive a upgrade even if the rest of /usr gets formatted * /usr/share is a seperate FS as I've discussed previously It may grow as I add fonts etc * /usr/tmp is ... well it's another tmp FS. I have it as a symlink to /var/tmp but that's a decision I made. You might have it as another mounted FS. * /usr/src is where (some) development gets done. Sources there may also draw on /usr/include. I want those to survive a new installation for are also separate file systems. How large each of these file systems are will depend on many things. If you decide never to work on system packages perhaps /usr/src and /ur/include will never be populated so aren't separate file systems. Perhaps. Perhaps you are a game player and some games come with large databases, so that warrants /usr/games being a separate FS. Perhaps. As it stands, the solution to your overpopulated /usr might not be to move *all* of /usr to a larger partition but to create a partition for, say, /usr/share and move that off. Actually that's what I did many years ago. And it was easy for me to do as I had already adopted LVM.
Thanks Carlos for your guidance, just to be clear, (the devil is in the details as always...) the steps I think you are saying that I need to follow is - ?
1. Use Yast2 Partitioner to create a new partition and mount it as /usr_new
Well, no. I'd mount a RESCUE system and do it all from there.
2. su root
3. cd /usr
4. cp -a * /usr_new
Err, no, I would use RSYNC to d any such copy.
5. Edit fstab so as to change the mount my new partition from /usr_new to /usr
now I am a bit unsure, I think I want to rename /usr to something else so that later I can delete it and recover the space, but the moment I do, I break a whole lot of the system!
As I said, moving off /usr/share is less dramatic. if you get it wrong what have you lost? Or you might try it in a more granular way, move off /usr/share/man. # du -sh /usr/share/{doc,man,fonts} 483M /usr/share/doc 47M /usr/share/man 138M /usr/share/fonts John Anderson could call this a rounding error, and sicne I use LVM and can easily grow or shrink a FS and partition I can't argue. I could easily rsync the above and more off onto one of the 1G USB sticks that are free give-away at conferences (such as SUSE DAYS marketing presentations each year) and do some cleanup, the put them back, possibly with symlinks. For the most part I use ReiserFS rather than ext4. Ext4 is a wonderful FS but has one strange design limit. In a world where every other B-tree based FS has moved away from the old V7 FS model of having a certain fixed number of inodes and their space set at mkfs-time, ext4 has stuck with it. So it can mean that you have run out of data space but there is still a lot of free space on the disk psrtition, but it is preallocated for inodes. XFS, ReiserFS, BtrFS, the other B-tree file systems that are popular, do not have this limitation. Many people see this as an irrelevancy. I see it as being stuck with a 1960s view of resource allocation.
7. mkinitrd
8. reboot
Well, the nice thing about using LVM and growing a file system such as reiserFS using the LVM tools is that you can do it on a live system. No need to do a new mkinitrd, no need to reboot. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org