[opensuse] Re: Why is initrd needed...
Andrey Borzenkov wrote:
- mount by LABEL/UUID/whatever, but not by /dev/sdX. Uncountable times I got support call after adding some additional storage after installation and staying before system that does not boot.
For "truth in advertising"... I do use device id's in one place -- lilo.conf. It didn't parse names there when I wrote it 5 years ago, dunno about now. however, if your addition of disks has changed the "sd" ordering, it won't boot from the correct disk and your initrd won't be loaded either. Of major note -- I had a suse install install it's boot kernel and init rd on a different partition than boot (this was some time ago, it may read the info from the BIOS now), but the result was that it updated an unused partition to boot from, and updated the boot sector on a disk that the machine didn't boot from. The result was it booted from my old kernel (which was newer than the one the distro was installing) from a different disk -- and then proceeded to mount the updated root. I.e. my 'boot' partition is separate from root. Nothing is on the boot partition except the kernel images (this is true when it used the suse initrd boot as well, as both lilo and grub support separate boot and root partitions. My boot system continued to work, as it was configured knowing the bios configuration, the suse method, at that time, didn't. and updated an unused parition for boot (thought it correctly updated my root partition). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Nov 15, 2012 at 12:21 PM, Linda Walsh <suse@tlinx.org> wrote:
however, if your addition of disks has changed the "sd" ordering, it won't boot from the correct disk and your initrd won't be loaded either.
This is slightly off-topic: Linda, I admit that is a struggle because I reconfigure computer drives all the time. Each bios seems to have it's own way to break the boot process as drives, thumbs, USB DVD drives are added and removed. I bought a nice Intel MB a couple weeks ago. It was the first one I have seen that had a "static" option. Basically you connect up the drives you think you will use, then tell the bios to create a static boot sequence. From that point on, the bios quits futzing with it and lets you boot what you told it were boot devices. If one of your static devices is thumb drive and you boot without it, the boot table is not updated. If later on I do need to force a new boot device (USB thumb, USB DVD, eSata, etc.) I assume I will have to play with the bios a little to make it happen, but for the 99% of time I actually want to boot from the default boot device, I know have a stable solution. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
however, if your addition of disks has changed the "sd" ordering, it won't boot from the correct disk and your initrd won't be loaded either. This is slightly off-topic: Linda, I admit that is a struggle because I reconfigure computer drives all the time. Each bios seems to have it's own way to break the boot process as drives,
On Thu, Nov 15, 2012 at 12:21 PM, Linda Walsh <suse@tlinx.org> wrote: thumbs, USB DVD drives are added and removed. I bought a nice Intel MB a couple weeks ago. It was the first one I have seen that had a "static" option.
It's mostly Windows that is guilty of re-ordering drives in my experience. I can add/remove drives -- the main floppy, USB drives, Add/remove sata drives.. Doesn't affect my linux device names that I boot from on a Dell system. But it's *not* automatic. If I add new HW, I go into the BIOS and make sure it's still in the boot order I want. The only time it changes is if a drive before my boot drive is take out/removed, then the bios moves the drives "down". My 'a+b+ drives are SAS-based raid arrays, which I tell the bios to mount first. But I boot off of drive C, the same as when I had 2 floppies there. I can add/remove CD's, as they aren't disks, they don't change anything, if I add a SATA disk -- still doesn't matter -- as I tell my BIOS to boot off-board (meaning in a slot, vs. soldered), cards first and I tell it the order to be the card in slot 0 vs. slot 5). Barring me taking drives (there are 2 RAID-based drives attached to the card in slot 0). Another reason I have "smallish" system drives .. I use 15K SAS drives which are smaller. To get the space I have & optimize speed, I 'short-stroke' the array, using only the first half of 3-72GB drives, with 1 being parity. Effectively I only have 72GB for all of '/', '/usr', 'var, var/cache, swap, boot. My larger storage disks are everything else -- all 2TB 7200 SATA's hooked up to a RAID SAS controller, split between "sda" and "sdb". sdb for backups is a RAID6 6 data disks. sda is my main work disk -- which is split into volumes using lvm -- seek times aren't as fast as on the root HD, but linear speeds are good -- it's configured as a RAID50 using 3 groups of 5. The 1 disk left over is a global spare. I don't even have room for /usr/share on the root drives anymore -- it grew too big -- so my /usr/share lives on /home/share, which is then mounted via bind to /usr/share. One thing that doesn't get advertised much, is that /usr/share -- specifically meant to be non-arch-specific, shared-content, is ALSO being required now in order to boot. So it's not just /usr, but /usr/share as well (and likely others will be added over time). But as an example, my /usr/share is in /home/share, that means /home needs to be mounted as well -- all of this worked fine under 12.1. Even with /usr mounted, the newest stuff in factory won't necessarily boot -- as /usr/share wasn't mounted. Now maybe that's because /home (on an lvm based device) wasn't mounted, or maybe they didn't also mount / process the 'binds' and 'rbinds', or maybe they didn't do it in the right order: 1. / (root) 2. /usr 3. /home 4. /usr/share (from /home/share). I don't know where it failed, as I had to mount /usr/ manually and call boot & init scripts after that. Note -- my boot failed because of a new, added, "screw-you" check (one that catches a compliance error but serves no useful purpose). Someone put in a superfluous and ill-considered check to make sure your root disk is read-only upon booting, because they "know"[sic], that you can't run a file system's "fsck" script on a writable disk. But that's just stupid -- for 2 reasons: 1) if fsck can't run due to a disk being writable, then it will die with an error saying it can't do the check -- so the first check is redundant. 2) if fsck CAN run with a disk being writable, then the extra check just screws you over -- for no technical reason. Again, this is an example of changes going in with no thought behind them (or, worse, with deliberate malicious intent). I'm presuming that they simply didn't use their brain and didn't think the logic through -- which given the choices -- is actually a positive assessment. I also had the mount for /dev/hugetbls fail -- because it's mount point had not been created on /dev. Why? because udev exited early -- because /usr/share/somthing wasn't available to process some other device! As near as I can tell, some very seriously screwed circular dependencies are in the making that will make bringing up a system from any sort of 'problem state', near impossible -- that is the "benefit" of moving to a separate /usr and forcing initrd. In my case, udev needed to create devices, but exited / died when it couldn't access something in /usr/share -- that wasn't there because /dev wasn't populated to allow mount of /home/share. It's bad enough when one can't mount /usr because mount is on /usr, but if you can't get udev running, and that forces /usr/share to not be mountable (which udev needs), OpenSuse has created a maintenance nightmare. The idea of spreading dependencies out across all of the disks is going to lead to more circular logic problems (just like the need to mount /usr one needs 'mount', but some rocket scientist put that in /usr/bin. Of course the idea of mounting is 'moot' anyway, since a reason given for needing initrd was to check disks if they needed it (fsck)... he pointed to xfs_repair (usually only run after xfs_check, in my experience) -- neither of which is even on initrd, let alone called as part of any boot process. So if /usr doesn't mount -- you can't check it anyway, so the idea that you need initrd to precheck the disks is also moot. Someone else suggested that you needed to decrypt disks -- but if that was true, how can you read initrd or the boot image if they are encrypted? Isn't it true that those routines need to be already built into your kernel if you want to use them? If you want an encrypted root disk, then you can preboot from a ram disk(initrd), but to decrypt it requires the decryption be built into the kernel -- if you do that, you also need the ram disks and loopback support builtin. I would be surprised if the linux kernel didn't have a way of booting with an encrypted root, w/o an initrd. Do you see how many problems just mounting /usr in initrd can be. It's known to be unreliable (I've had failures with unbootable systems in the past, and factory required a rescue disk to boot all of last week to get around initrd bugs). It's NOT just 1 bad thing .. it's several at this point and the number will continue to climb as people insist on going down this poorly thought out path. Let Red Hat commit Hari Kari alone -- it will only help those who don't follow the head lemming. If they finish their work and still have customers... and it shows any benefit -- maybe THEN consider moving in that direction, but as it stands now, you can get the same benefits without kneecapping yourself. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Another reason I have "smallish" system drives .. I use 15K SAS drives which are smaller. To get the space I have & optimize speed, I 'short-stroke' the array, using only the first half of 3-72GB drives, with 1 being parity. Effectively I only have 72GB for all of '/', '/usr', 'var, var/cache, swap, boot.
That ought to be more than plenty, even for a desktop machine? I mean, I usually allocate 10Gb for a server (without data volumes), and a typical install will usually take up about 2-3Gb.
I don't even have room for /usr/share on the root drives anymore -- it grew too big -- so my /usr/share lives on /home/share, which is then mounted via bind to /usr/share.
Hmm, you have 72Gb for your root filesystem, but not enough for /usr/share ??
One thing that doesn't get advertised much, is that /usr/share -- specifically meant to be non-arch-specific, shared-content, is ALSO being required now in order to boot.
I agree, I haven't seen that mentioned, but then I also haven't seen (m)any convincing reasons for keeping it on a separate filesystem.
So it's not just /usr, but /usr/share as well (and likely others will be added over time). But as an example, my /usr/share is in /home/share, that means /home needs to be mounted as well -- all of this worked fine under 12.1.
Even with /usr mounted, the newest stuff in factory won't necessarily boot -- as /usr/share wasn't mounted.
Right.
Someone put in a superfluous and ill-considered check to make sure your root disk is read-only upon booting, because they "know"[sic], that you can't run a file system's "fsck" script on a writable disk.
I could be wrong, but hasn't openSUSE been like that for years and years? I.e. first mount root read-only, then remount as read-write? I built a smallish cluster with SUSE 8.0, I seem to remember stuff like that when I started taking things apart (for booting with root on NFS).
It's bad enough when one can't mount /usr because mount is on /usr, but if you can't get udev running, and that forces /usr/share to not be mountable (which udev needs), OpenSuse has created a maintenance nightmare.
Isn't your /usr/share issue a bit contrived, Linda?
The idea of spreading dependencies out across all of the disks is going to lead to more circular logic problems (just like the need to mount /usr one needs 'mount', but some rocket scientist put that in /usr/bin.
I also find the move /usr to be a solution looking for a problem, but I personally don't have a real problem with it as long as /usr can still be put on a separate filesystem (nfs etc). I guess that is taken care of by keeping /usr/bin/mount in the initrd. -- Per Jessen, Zürich (3.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-19 08:54, Per Jessen wrote:
Linda Walsh wrote:
Someone put in a superfluous and ill-considered check to make sure your root disk is read-only upon booting, because they "know"[sic], that you can't run a file system's "fsck" script on a writable disk.
I could be wrong, but hasn't openSUSE been like that for years and years? I.e. first mount root read-only, then remount as read-write? I built a smallish cluster with SUSE 8.0, I seem to remember stuff like that when I started taking things apart (for booting with root on NFS).
AFAIK, yes. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCqLQ8ACgkQja8UbcUWM1wvUwD/SIebloMePuS0Aai4D1KOv3+S ao83pjLH46dgSdRXjUQBAJX50UwRZtH6llM9MY0/gVYeSUTjhQk5X87jI/Tn0dB+ =sFUp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Linda Walsh wrote:
Another reason I have "smallish" system drives .. I use 15K SAS drives which are smaller. To get the space I have & optimize speed, I 'short-stroke' the array, using only the first half of 3-72GB drives, with 1 being parity. Effectively I only have 72GB for all of '/', '/usr', 'var, var/cache, swap, boot.
That ought to be more than plenty, even for a desktop machine? I mean, I usually allocate 10Gb for a server (without data volumes), and a typical install will usually take up about 2-3Gb.
I don't even have room for /usr/share on the root drives anymore -- it grew too big -- so my /usr/share lives on /home/share, which is then mounted via bind to /usr/share.
Hmm, you have 72Gb for your root filesystem, but not enough for /usr/share ??
73GB is usable for the root Hard disk -- not '/' HD: Isn't /var, and /tmp also needed for boot .. Also I tried to create my disks such that they'd have no more than 60% usage, 75% being the worst for a system disk (of these sizes == not same percentages for TB disks)... 128M /boot 1 swap 4 /var (+ /tmp mounted on /var/rtmp) -extended- 6 / 10 9.2 /usr Number Size Type File system 1 13GB primary xfs type=83 (root or "/") 64MB, boot 2 8.5GB primary xfs type=83 (/var + /tmp) 3 1GB primary xfs boot, type=83 (boot) [4 49.5GB extended type=05 (---) 5 8.5MB logical swap(v1) type=82 (swap) 6 16.1GB logical xfs type=83 (/usr/) 7 10.7GB logical xfs type=8 (/var/cache) ] ---- 72GB total 15G (/usr/share - another device).
One thing that doesn't get advertised much, is that /usr/share -- specifically meant to be non-arch-specific, shared-content, is ALSO being required now in order to boot.
I agree, I haven't seen that mentioned, but then I also haven't seen (m)any convincing reasons for keeping it on a separate filesystem.
---- I didn't have room? I would have kept it with /usr, but ran out of space on my root disk...
Right.
Someone put in a superfluous and ill-considered check to make sure your root disk is read-only upon booting, because they "know"[sic], that you can't run a file system's "fsck" script on a writable disk.
I could be wrong, but hasn't openSUSE been like that for years and years?
---- On this one -- it may be it has been there, and I only recently changed to mounting my rootfs 'rw', as there is no need to mount it 'ro' for 'fsck'.. as fsck doesn't check or need it to be. My workaround was to "chkconfig boot.rootfsck off" as it is not needed. If only instead of boot.localfs, they had boot.localfsck as a separate pre-step, then I wouldn't have to bother with making /bin/fsck.xfs a link to /bin/true. Good thing it was a hard-link, or it would have failed.
It's bad enough when one can't mount /usr because mount is on /usr, but if you can't get udev running, and that forces /usr/share to not be mountable (which udev needs), OpenSuse has created a maintenance nightmare.
Isn't your /usr/share issue a bit contrived, Linda?
--- Not at all... 15K SCSI drives (now SAS) aren't the size of SATA's... They are up to about 450GB now with SATA @ 3TB, but when SATA was at 1TB, SAS's were about 143, and when SATA was ATT and SAS was SCSI, SCSI drives were in the 18.2 for 'cheap', and 36.4 for expensive. That's about when I setup my 1st server on a workstation. This server's root was setup with 73GB was reasonable, and 146GB was affordable, BUT -- compared to 1TB SATA's, .. so the system disks got a short-stroked, 3-disk RAID5 with cheap 73GB disks @ 15.5K speed -- with the short stroking, cuts the the nominal seek time from 5-6ms, down to 2-3ms. Figured that was fine for my boot files.. The shorter seek times are good for booting. So really, when /usr/share grew to ~ 20GB by itself (I think I have it down to about 15GB used now, but not as much SW installed, it pegged out /usr... So I moved it to my /home partition that's slower on seeks but faster on large fiels (RAID50). So not contrived in the slightest.
I also find the move /usr to be a solution looking for a problem, but I personally don't have a real problem with it as long as /usr can still be put on a separate filesystem (nfs etc). I guess that is taken care of by keeping /usr/bin/mount in the initrd.
--- If you look in initrd, for /usr/bin/mount, you won't find it. It's in "/bin".... ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Per Jessen wrote:
Linda Walsh wrote: [snip]
I don't even have room for /usr/share on the root drives anymore -- it grew too big -- so my /usr/share lives on /home/share, which is then mounted via bind to /usr/share.
Hmm, you have 72Gb for your root filesystem, but not enough for /usr/share ??
73GB is usable for the root Hard disk -- not '/' HD: Isn't /var, and /tmp also needed for boot ..
Sure, I tend to include everything when I say root :-)
Also I tried to create my disks such that they'd have no more than 60% usage, 75% being the worst for a system disk (of these sizes == not same percentages for TB disks)...
Okay, fair enough. I can still easily fit a server into 16Gb with 6Gb to spare. (without data volumes)
128M /boot 1 swap 4 /var (+ /tmp mounted on /var/rtmp) -extended- 6 / 10 9.2 /usr
Number Size Type File system 1 13GB primary xfs type=83 (root or "/") 64MB, boot 2 8.5GB primary xfs type=83 (/var + /tmp) 3 1GB primary xfs boot, type=83 (boot) [4 49.5GB extended type=05 (---) 5 8.5MB logical swap(v1) type=82 (swap) 6 16.1GB logical xfs type=83 (/usr/) 7 10.7GB logical xfs type=8 (/var/cache) ] ---- 72GB total 15G (/usr/share - another device).
I'm sure you have your reasons, and it will of course depend on what that box does. I'm just setting up a xen guest for migrating an elderly mailserver cluster from 10.2 to 12.2 - it will essentially be running postfix and mysql plus a number of custom written daemons: Partition #1 - swap (1Gb) Partition #2 - root (~12Gb) (no data volumes on this box). My /usr/share is 191Mb. /var/cache is about 50Mb. Mail is only stored during processing.
One thing that doesn't get advertised much, is that /usr/share -- specifically meant to be non-arch-specific, shared-content, is ALSO being required now in order to boot.
I agree, I haven't seen that mentioned, but then I also haven't seen (m)any convincing reasons for keeping it on a separate filesystem.
I didn't have room? I would have kept it with /usr, but ran out of space on my root disk...
Not convincing enough for me - I mean, if you need space, buy a bigger disk. (what on earth do you keep in /usr/share?) In principle requiring /usr/share for booting is probably not a good idea, but I don't see it being a frequent real world problem.
It's bad enough when one can't mount /usr because mount is on /usr, but if you can't get udev running, and that forces /usr/share to not be mountable (which udev needs), OpenSuse has created a maintenance nightmare.
Isn't your /usr/share issue a bit contrived, Linda?
Not at all... 15K SCSI drives (now SAS) aren't the size of SATA's... They are up to about 450GB now with SATA @ 3TB, but when SATA was at 1TB, SAS's were about 143, and when SATA was ATT and SAS was SCSI, SCSI drives were in the 18.2 for 'cheap', and 36.4 for expensive.
SATA drives have even moved into 4Tb sizes these days, but I also have a lot of those 15K SCSI drives about (36/72/146/300Gb) in servers.
So really, when /usr/share grew to ~ 20GB by itself (I think I have it down to about 15GB used now, but not as much SW installed, it pegged out /usr...
Wow. Even my main workstation has only 1.5Gb in /usr/share. -- Per Jessen, Zürich (3.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Linda Walsh wrote:
Per Jessen wrote:
Linda Walsh wrote: [snip]
I don't even have room for /usr/share on the root drives anymore -- it grew too big -- so my /usr/share lives on /home/share, which is then mounted via bind to /usr/share. Hmm, you have 72Gb for your root filesystem, but not enough for /usr/share ??
73GB is usable for the root Hard disk -- not '/' HD: Isn't /var, and /tmp also needed for boot ..
Sure, I tend to include everything when I say root :-)
Also I tried to create my disks such that they'd have no more than 60% usage, 75% being the worst for a system disk (of these sizes == not same percentages for TB disks)...
Okay, fair enough. I can still easily fit a server into 16Gb with 6Gb to spare. (without data volumes)
I'm sure you have your reasons, and it will of course depend on what that box does.
--- Everything. DNS/backups/squid/Samba/Domainserver, mailserver + filter (sendmail+spamd+Dovecot-Imapd)/Time, Home+doc servers for Windows (it a profile server);router;sockserver;torrent-server;WPAD server; HW+NTWrk monitoring; In process (keeps breaking) of bringing up WinXP64 for local Win7 compat indexing; Media server; upnp server; Docserver. Those are most of the things I can think of off hand.
My /usr/share is 191Mb. /var/cache is about 50Mb. Mail is only stored during processing.
My /usr/share/man in 192MB by itself. Guess you don't do any SW on your /usr/share. But 6.4G=>fonts, 2.0G->doc, 2.2G->texmf, 752M->icons, 288->locale ... it adds up... My var/cache WAS large for squid, but now I have put it on it's own partition /var/cache/squid -- so that could be smaller or eliminated as a separate partition. ----
One thing that doesn't get advertised much, is that /usr/share -- specifically meant to be non-arch-specific, shared-content, is ALSO being required now in order to boot. I agree, I haven't seen that mentioned, but then I also haven't seen (m)any convincing reasons for keeping it on a separate filesystem.
I didn't have room? I would have kept it with /usr, but ran out of space on my root disk...
Not convincing enough for me - I mean, if you need space, buy a bigger disk. (what on earth do you keep in /usr/share?)
(see above) -- It's not just about the money -- but Not really wanting to reformat root just to make it bigger. I don't have spare slots to put to use for a reformat, though I might think about going to SSD's for the root partition... But going through HW upgrades just because someone, on a whim changed SW...
SATA drives have even moved into 4Tb sizes these days, but I also have a lot of those 15K SCSI drives about (36/72/146/300Gb) in servers.
---- But prices haven't moved down and income is limited. In more flush times I would have replaced the disks by now, but have other higher priority items to spend money on... more memory for one.. though the disk space for the root fs is on 15K SAS drives -- they don't come in larger sizes except at a price. I'll admit to wavering on the /usr being on "/", BUT .. at the same time, I don't see why it needs to be done. There isn't a software need for it. So it gratuitous change to something that will affect tons of 3rd party sw for years to come. NO friggin way /bin/bash is going to be movable without complete chaos... Too many scripts -- all hardcoded... and they HAVE to be hard coded -- no one every expected the system binaries to not live in /bin -- especially the shell(s). Everything that is done on initrd could be done on the rootfs, which would then start the rest of the boot.
So really, when /usr/share grew to ~ 20GB by itself (I think I have it down to about 15GB used now, but not as much SW installed, it pegged out /usr.
Wow. Even my main workstation has only 1.5Gb in /usr/share.
Yeah... well see my biggies above...Got more in /usr/share/docs than that... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Per Jessen wrote:
I'm sure you have your reasons, and it will of course depend on what that box does.
--- Everything.
DNS/backups/squid/Samba/Domainserver, mailserver + filter (sendmail+spamd+Dovecot-Imapd)/Time, Home+doc servers for Windows (it a profile server);router;sockserver;torrent-server;WPAD server; HW+NTWrk monitoring; In process (keeps breaking) of bringing up WinXP64 for local Win7 compat indexing; Media server; upnp server; Docserver.
Those are most of the things I can think of off hand.
My /usr/share is 191Mb. /var/cache is about 50Mb. Mail is only stored during processing.
My /usr/share/man in 192MB by itself.
Guess you don't do any SW on your /usr/share.
/usr/share contains whatever the packages put in there. Otherwise I rarely touch it. As for software, no, I tend to keep the selection very specific to what a server is meant to do.
But 6.4G=>fonts, 2.0G->doc, 2.2G->texmf, 752M->icons, 288->locale ... it adds up...
One difference is that my servers don't have things like fonts and icons, for instance. I guess your /usr/share/locale being 288Mb indicates how much software you install - on a new 12.2 server, I have only 31M, but then the entire system incl. data fits just about 2Gb.
My var/cache WAS large for squid, but now I have put it on it's own partition /var/cache/squid -- so that could be smaller or eliminated as a separate partition.
Yes, that's what I call data and I always keep it on separate volumes.
I agree, I haven't seen that mentioned, but then I also haven't seen (m)any convincing reasons for keeping it on a separate filesystem.
I didn't have room? I would have kept it with /usr, but ran out of space on my root disk...
Not convincing enough for me - I mean, if you need space, buy a bigger disk. (what on earth do you keep in /usr/share?) (see above) -- It's not just about the money -- but Not really wanting to reformat root just to make it bigger. I don't have spare slots to put to use for a reformat, though I might think about going to SSD's for the root partition...
But going through HW upgrades just because someone, on a whim changed SW...
Well, put like that, I agree, but your case still sounds like a corner-case that it probably doesn't make sense for openSUSE to cater for.
SATA drives have even moved into 4Tb sizes these days, but I also have a lot of those 15K SCSI drives about (36/72/146/300Gb) in servers.
But prices haven't moved down and income is limited.
Price per Gb has moved down, but I know what you mean. Still, a 1Tb SATA drive can be had for less EUR100.
I'll admit to wavering on the /usr being on "/", BUT .. at the same time, I don't see why it needs to be done. There isn't a software need for it. So it gratuitous change to something that will affect tons of 3rd party sw for years to come.
Agreed, I also see little reason for doing it, but personally I've stopped playing Don Quixote. -- Per Jessen, Zürich (3.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
My /usr/share is 191Mb. /var/cache is about 50Mb. Mail is only stored during processing.
FWIW -- I just merged /var/cache (~330MB back to var), due to your questions... It didn't make sense... ;-)
Well, put like that, I agree, but your case still sounds like a corner-case that it probably doesn't make sense for openSUSE to cater for.
I dunno about that -- most corporations tend toward being conservative. There is a strong tendency toward "if it isn't broke, don't fix it"... Useless moving around of partitions that serve no purpose other than reorganizing is never done unless it is of business necessity or the cost to it is near zero in terms of money, time and risk. If it is, the the cost/benefit is low enough to justify.
SATA drives have even moved into 4Tb sizes these days, but I also have a lot of those 15K SCSI drives about (36/72/146/300Gb) in servers.
But prices haven't moved down and income is limited.
Price per Gb has moved down, but I know what you mean. Still, a 1Tb SATA drive can be had for less EUR100.
--- No slots. Currently except for the 3 15KSAS, drives they are all filled with 2T SATA's.
I'll admit to wavering on the /usr being on "/", BUT .. at the same time, I don't see why it needs to be done. There isn't a software need for it. So it gratuitous change to something that will affect tons of 3rd party sw for years to come.
Agreed, I also see little reason for doing it, but personally I've stopped playing Don Quixote.
Unlike the move /var/cache -> cache, which makes no difference, the move of software from / to /usr is a poor business choice with huge risks. Moving /usr to / when before this, / contained all the necessary SW to boot to single user, but not requiring it to have all the software to support "level 5", is a poor business choice and is risky. The cost in terms of risk, changing of existing programs and scripts reliability, security, is enormous and so far, not one of the backers has created any "benefit" for this that can't be solved without doing it. As such it's a poor engineering design and bad engineering and parallels lemmings following the lead off of a cliff. Those who followed Jim Jones on his Koolaid adventure are not around anymore. I hardly think standing up to a cult-mentality is comparable to tilting at windmills. Note -- while I often take opposing views on matters, I more often than not back down when the danger isn't worth the effort and I can moderate my risk, but so often on this list, there is the inside group that has already made the choices and the masses are expected to follow -- with a façade of openness that is used to lure in free workers. I find that attitude reprehensible, at *best*. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
Andrey Borzenkov wrote:
- mount by LABEL/UUID/whatever, but not by /dev/sdX. Uncountable times I got support call after adding some additional storage after installation and staying before system that does not boot.
For "truth in advertising"... I do use device id's in one place -- lilo.conf. It didn't parse names there when I wrote it 5 years ago, dunno about now.
Works fine. -- Per Jessen, Zürich (5.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Carlos E. R. -
Greg Freemyer -
Linda Walsh -
Per Jessen