Re: unchecked 31 times
On Sat, 31 Jan 2004 20:30:13 -0600, Will Trillich wrote: On Tue, Dec 02, 2003 at 03:56:25PM -0500, Paul Morgan wrote: My understanding is that lilo works off a system map which is created at installation and is sector based. So, as long as it can figure out where the kernel is physically placed at installation, it can map it. Then, when loading the kernel, it doesn't have to care about the filesystem. So the boot loader can be tiny. Grub is different. It has to grok the filesystem at boot time, so the boot loader is huge as a result. Oh, and lilo can boot off a RAID device. eh? is it possible to get woody to boot (after installing, and no luck there, yet) off of a raid? that would be awesome. i've got a 3ware setup, and 3w-.o is what's needed, which works fine under morphix, but i've not been able to preload the module under the woody install. (floppy 'driver' images won't mount, and i've tried about three different download sites to get them...) got pointers? I don't use RAID myself, but I would suggest looking though the howtos at tldp.org, I'm sure there must be something about booting off RAID. But I DO know that lilo can do this. -- paul It is important to realize that any lock can be picked with a big enough hammer. -- Sun System Network Admin manual -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Sat, 2004-01-31 at 21:30, Will Trillich wrote: On Tue, Dec 02, 2003 at 03:56:25PM -0500, Paul Morgan wrote: My understanding is that lilo works off a system map which is created at installation and is sector based. So, as long as it can figure out where the kernel is physically placed at installation, it can map it. Then, when loading the kernel, it doesn't have to care about the filesystem. So the boot loader can be tiny. Grub is different. It has to grok the filesystem at boot time, so the boot loader is huge as a result. Oh, and lilo can boot off a RAID device. eh? is it possible to get woody to boot (after installing, and no luck there, yet) off of a raid? that would be awesome. i've got a 3ware setup, and 3w-.o is what's needed, which works fine under morphix, but i've not been able to preload the module under the woody install. (floppy 'driver' images won't mount, and i've tried about three different download sites to get them...) I installed woody on my IBM ServeRAID card, though I had to make a custom boot disk which provided a kernel supporting my RAID card. Most likely, you are unable to install because the install kernel you are using doesnt support your 3ware card. I would suggest that you make sure that you are using the bf24 kernel to install (F3 at CD boot prompt), because I thought I remembered that kernel having support for 3ware compiled in..., but if not, you may need to make yourself a custom boot disk (see http://www.debian.org/releases/stable/i386/ch-boot-floppy-techinfo.en.html#s-rescue-replace-kernel) -davidc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Tue, Dec 02, 2003 at 03:56:25PM -0500, Paul Morgan wrote: My understanding is that lilo works off a system map which is created at installation and is sector based. So, as long as it can figure out where the kernel is physically placed at installation, it can map it. Then, when loading the kernel, it doesn't have to care about the filesystem. So the boot loader can be tiny. Grub is different. It has to grok the filesystem at boot time, so the boot loader is huge as a result. Oh, and lilo can boot off a RAID device. eh? is it possible to get woody to boot (after installing, and no luck there, yet) off of a raid? that would be awesome. i've got a 3ware setup, and 3w-.o is what's needed, which works fine under morphix, but i've not been able to preload the module under the woody install. (floppy 'driver' images won't mount, and i've tried about three different download sites to get them...) got pointers? -- I use Debian/GNU Linux version 3.0; Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown DEBIAN NEWBIE TIP #16 from Will Trillich [EMAIL PROTECTED] : Why are *.rpm (RED HAT PACKAGES) considered spawn of Satan? Because the Debian package system is a lot more sophisticated than the one Red Hat uses; lots more inter-dependency information is built in to a *.deb package. If you bypass that with an *.rpm file, you're taking chances with your system. Try to apt-get install debian-only packages if possible. (Also check out the alien package if you must.) Also see http://newbieDoc.sourceForge.net/ ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
On Wed, Dec 03, 2003 at 12:17:52PM -0800, Mark Ferlatte wrote: Minor nit: netatalk requires a device node in /var to support Appletalk printing. Admittedly, for most people, this is not an issue. Not arguing, but what device node? Where? When did this start? What creates it? The package doesn't own any files in /var, and I can't see anywhere in its postinst that it creates such a node. I print to an ethertalk-interfaced LaserWriter all the time... if it was supposed to be there, and wasn't, I don't think I'd be printing much. -- Marc Wilson | Lactomangulation, n.: Manhandling the open here [EMAIL PROTECTED] | spout on a milk carton so badly that one has to | resort to using the illegal side. -- Rich Hall, | Sniglets signature.asc Description: Digital signature
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
on Wed, Dec 03, 2003 at 12:17:52PM -0800, Mark Ferlatte ([EMAIL PROTECTED]) wrote: Karsten M. Self said on Wed, Dec 03, 2003 at 06:15:29AM -0800: See, variously, the FHS, and my own partitioning guidelines: http://twiki.iwethey.org/Main/NixPartitioning Good page. I should have known about the Jihad. ;-) Thanks. I'll have to re-check my sizing recommendations for /. Current stock kernels run ~23 MiB with all modules. This plus journal files leaves me pinched on a couple of systems with what was once an adequate 96 MiB. Depending on kernel growth, 200 MiB or more might not be unwarranted. Much revision of /etc might help here. - /var need only be writeable and executable (nodev, nosuid). Minor nit: netatalk requires a device node in /var to support Appletalk printing. Admittedly, for most people, this is not an issue. While it's not current policy, the practice of sequestering _all_ device files under /dev would be *highly* encouraged by this punter. Both devfs (deprecated) and hotplug should help in this regard. - Minimal damage. Any actions affecting a partition are limited to that partition. - Minimal damage. The probabilities of corruption of a partition are directly proportional to its size. Minimize the size, minimize this likelihood. I think I'm approaching this problem from a difference perspective; it takes less time for me to rebuild a system from scratch than it would to recover the system partitions (automated rebuild and system config recovery and all that), so this problem doesn't really affect me much. There are a few different viewpoints to this. Given that 30% of spam is reported (Inquirer news story 3 Dec) to originate from broadband-connected systems, minimizing the exposed vulnerabilities of _any_ system should be a high priority. Specifically: allow device and SUID access only where absolutely necessary, keep system partitions mounted read-only if possible, protect and/or isolate your kernel(s). Well, for starters, /tmp *is* cleared between system boots, and is appropriate for data which *must* not be preserved between boots. The definitions are not identical, the directories are not equivalent. Your definition above is much stricter than what the FHS actually says, and under your definition /tmp and /var/tmp are not equivalent. Fair enough. The FHS allows for what Debian policy requires. Peace. -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Bush/Cheney '04: Asses of Evil pgp0.pgp Description: PGP signature
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
Karsten M. Self [EMAIL PROTECTED] [2003:12:03:06:15:29-0800] scribed: snip / See, variously, the FHS, and my own partitioning guidelines: http://twiki.iwethey.org/Main/NixPartitioning snip / Since Debian places logfiles under /var/log, I always create a separate /var/log partition. If logfiles ever spew out of control, my systems continue to function . . . Is there some reason *not* to protect the rest of /var? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
Marc Wilson said on Wed, Dec 03, 2003 at 11:01:12PM -0800: On Wed, Dec 03, 2003 at 12:17:52PM -0800, Mark Ferlatte wrote: Minor nit: netatalk requires a device node in /var to support Appletalk printing. Admittedly, for most people, this is not an issue. Not arguing, but what device node? Where? When did this start? What creates it? The package doesn't own any files in /var, and I can't see anywhere in its postinst that it creates such a node. It may not require it anymore. A while back, I had to setup Appletalk printing to a Linux server (using papd), and it required that every papd printer spool have its own null device. If you only have one printer, then /dev/null was fine; if you had more, the docs suggested making a null device in each spool. I don't know if this is still necessary, but as I said; it certainly doesn't affect many people, and you probably can place all of the null device files into /dev anyway. M pgp0.pgp Description: PGP signature
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
Karsten M. Self said on Thu, Dec 04, 2003 at 03:35:54AM -0800: Given that 30% of spam is reported (Inquirer news story 3 Dec) to originate from broadband-connected systems, minimizing the exposed vulnerabilities of _any_ system should be a high priority. Specifically: allow device and SUID access only where absolutely necessary, keep system partitions mounted read-only if possible, protect and/or isolate your kernel(s). What I am trying to determine is the simplest safe partition configuration, assuming that the issue of system recovery from a damaged partition is moot and does not depend upon the host that was damaged. Simplest is probably smallest number of, in this case. Your comments are most helpful. I especially like the small /boot, and leaving it unmounted most of the time. Well, for starters, /tmp *is* cleared between system boots, and is appropriate for data which *must* not be preserved between boots. The definitions are not identical, the directories are not equivalent. Your definition above is much stricter than what the FHS actually says, and under your definition /tmp and /var/tmp are not equivalent. Fair enough. The FHS allows for what Debian policy requires. Agreed. Debian policy requires that /tmp and /var/tmp are not the same location. M pgp0.pgp Description: PGP signature
LILO and bootloaders (was Re: unchecked 31 times)
on Mon, Dec 01, 2003 at 09:41:21PM -0500, Tom Vier ([EMAIL PROTECTED]) wrote: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. Regards LILO, incorrect. LILO doesn't read ext2. Or any other filesystem. It directly addresses the kernel by raw disk hardware address. And is subjec to a number of BIOS restrictions in this respect. GRUB, by contrast, _can_ read filesystems, and is best described as a minimal OS which has the basic function of falling on its own sword for the good of the Emperor Penguin (or other sundry OSs as you may have on your system). Peace. -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Reject EU Software Patents! http://swpat.ffii.org/ pgp0.pgp Description: PGP signature
FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
on Tue, Dec 02, 2003 at 02:20:05PM -0800, Mark Ferlatte ([EMAIL PROTECTED]) wrote: Paul Morgan said on Tue, Dec 02, 2003 at 03:49:52PM -0500: There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? I'm just curious as to the reasoning behind your partitioning scheme. M FHS says The contents of the root filesystem should be adequate to boot, restore, recover, and/or repair the system. Right... so, again with the why put /usr on a seperate partition from /? Making / large enough to hold /usr certainly fulfills the req of the contents of the root filesystem being adequate to boot, restore, recover and repair the system. See, variously, the FHS, and my own partitioning guidelines: http://twiki.iwethey.org/Main/NixPartitioning Among reasons: - Minimal privileges. / *must* be executable, suid, dev, and is generally writeable. By contrast: - /usr need only be executable and suid, and can be nodev and ro. - /tmp need only be writeable, though it's typically executable (some temporary scripts expect this), and in my experience only PCMCIA startup requires 'dev' (my own hacked PCMCIA startup does a remount,dev of /tmp if necessary, and remount nodev when completed). - /var need only be writeable and executable (nodev, nosuid). - /boot need not be mounted at all. - Minimal damage. Any actions affecting a partition are limited to that partition. - Minimal damage. The probabilities of corruption of a partition are directly proportional to its size. Minimize the size, minimize this likelihood. - Remote-mount / shareable. The FHS states that /usr and /home may be remotely mounted, read-only if appropriate for /usr. /usr cannot be split out if it is part of / (though a mount can be made over an existing directory subtree). - Minimal systems. Some systems have space constraints on boot media. In these cases, the root partition must have the tools required for booting, restoring, recovering, and/or repairing the system. But no more. /tmp and /var/tmp have different purposes. Check FHS again. Actually, I have both /tmp and /var/tmp on their own logical volumes. Okay, so neither your /tmp or /var/tmp volumes are available at boot time. The /tmp directory is. If booted to a minimal, root-only filesystem, it's possibl to write to /tmp. You should, of course, clear these files if created. So, why have a seperate /tmp and /var/tmp? According to the FHS 2.2, the only difference between /tmp and /var/tmp is that data in /var/tmp be more persistant than data in /tmp, but the only restriction on /tmp is that programs not assume that data in /tmp persists between invocations of a program. In other words, /var/tmp appears to completely fulfill the requirements of /tmp, which makes me wonder why they are seperate. Well, for starters, /tmp *is* cleared between system boots, and is appropriate for data which *must* not be preserved between boots. The definitions are not identical, the directories are not equivalent. You're strongly counseled to read standard texts on Unix administration such as Nemeth, et al. Peace. -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Moderator, Free Software Law Discussion mailing list: http://lists.alt.org/mailman/listinfo/fsl-discuss/ pgp0.pgp Description: PGP signature
Re: unchecked 31 times
Greg Folkert said on Tue, Dec 02, 2003 at 06:07:41PM -0500: On Tue, 2003-12-02 at 17:20, Mark Ferlatte wrote: Paul Morgan said on Tue, Dec 02, 2003 at 03:49:52PM -0500: Right... so, again with the why put /usr on a seperate partition from /? Making / large enough to hold /usr certainly fulfills the req of the contents of the root filesystem being adequate to boot, restore, recover and repair the system. /usr should NOT be needed to repair, recover, maintain, restore or boot. It goes against everything I have ever known about UNIX/Linux/*BSD. That's not what I suggested. I agree: the contents of /usr should not be needed to recover. However, just because it's not needed doesn't mean it couldn't be there, fairly safely from what I can tell. That's all I am trying to establish. /tmp and /var/tmp have different purposes. Check FHS again. Actually, I have both /tmp and /var/tmp on their own logical volumes. Okay, so neither your /tmp or /var/tmp volumes are available at boot time. So, why have a seperate /tmp and /var/tmp? Because it allows you to keep systems over runs from disabling the machine. Ever tried to access a machine with a FULL / and/or /var? Yes. It is unpleasant. I think there is a misunderstanding here, though: I'm not suggesting that /var/tmp or /tmp couldn't or shouldn't be a seperate partition. I am questioning the need for two seperate yet nearly identical temporary file locations that appear to have nearly identical semantics. I believe that Karsten's email points out some subtle differences between them, though. According to the FHS 2.2, the only difference between /tmp and /var/tmp is that data in /var/tmp be more persistant than data in /tmp, but the only restriction on /tmp is that programs not assume that data in /tmp persists between invocations of a program. In other words, /var/tmp appears to completely fulfill the requirements of /tmp, which makes me wonder why they are seperate. Because they are treated differently in practice... which allows something to store a map of stuff, or a session cache in /var/tmp and to use /tmp as a spillover area for temp data to be worked on. This is fair, although there is no real reason for the app to care that /tmp and /var/tmp are the same, provided there is sufficient space in the tmp partition. M pgp0.pgp Description: PGP signature
Re: unchecked 31 times
Monique Y. Herman [EMAIL PROTECTED] writes: On Tue, 02 Dec 2003 at 12:07 GMT, Juergen Stuber penned: Paul E Condon [EMAIL PROTECTED] writes: I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted file system? e.g. at 3am local time, or maybe 3pm for night owls? Or maybe while the machine is going down for the night? What's this, now? Machines don't need sleep! But I do, so sometimes I turn it off just to save some energy. Jürgen -- Jürgen Stuber [EMAIL PROTECTED] http://www.loria.fr/~stuber/ GPG key fingerprint: 962F E883 D7B5 F8B6 11CC 4375 8014 62D6 5F17 ADD7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
Karsten M. Self said on Wed, Dec 03, 2003 at 06:15:29AM -0800: See, variously, the FHS, and my own partitioning guidelines: http://twiki.iwethey.org/Main/NixPartitioning Good page. I should have known about the Jihad. - /var need only be writeable and executable (nodev, nosuid). Minor nit: netatalk requires a device node in /var to support Appletalk printing. Admittedly, for most people, this is not an issue. - /boot need not be mounted at all. This is clever. - Minimal damage. Any actions affecting a partition are limited to that partition. - Minimal damage. The probabilities of corruption of a partition are directly proportional to its size. Minimize the size, minimize this likelihood. I think I'm approaching this problem from a difference perspective; it takes less time for me to rebuild a system from scratch than it would to recover the system partitions (automated rebuild and system config recovery and all that), so this problem doesn't really affect me much. Okay, so neither your /tmp or /var/tmp volumes are available at boot time. The /tmp directory is. If booted to a minimal, root-only filesystem, it's possibl to write to /tmp. You should, of course, clear these files if created. Good point. If you wanted to consolidate /tmp and /var/tmp, the symlink would have to go the other direction. Well, for starters, /tmp *is* cleared between system boots, and is appropriate for data which *must* not be preserved between boots. The definitions are not identical, the directories are not equivalent. Your definition above is much stricter than what the FHS actually says, and under your definition /tmp and /var/tmp are not equivalent. Fair enough. M pgp0.pgp Description: PGP signature
Re: LILO and bootloaders (was Re: unchecked 31 times)
On Wed, 03 Dec 2003 05:52:00 -0800, Karsten M. Self wrote: on Mon, Dec 01, 2003 at 09:41:21PM -0500, Tom Vier ([EMAIL PROTECTED]) wrote: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. Regards LILO, incorrect. LILO doesn't read ext2. Or any other filesystem. It directly addresses the kernel by raw disk hardware address. And is subjec to a number of BIOS restrictions in this respect. Which means, of course, if you move the physical location of the system map or the kernel, you'd better rerun lilo, because it's not going to know where things are on the next boot, and this tends to lead to a lot of whining and crying (you, not lilo). For instance, not that anyone would do this (and *please don't*): cp -a /boot /boot-new rm -fr /boot mv /boot-new /boot reboot Then, if you're a cluebie, go to another computer and post an HTML message to debian-user saying lilo doesn't work in woody/sarge/sid, it was working yesterday, this never happened with Red Hat/Suse/FreeBSD, should I file a bug report? and everyone will be delighted to help you : sorry, couldn't resist -- paul I think that gay marriage is something that should be between a man and a woman. -- Arnold Schwarzenegger, Governor of California -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FHS and other things Mark should have read with comprehension (was Re: unchecked 31 times)
On Wed, 03 Dec 2003 06:15:29 -0800, Karsten M. Self wrote: You're strongly counseled to read standard texts on Unix administration such as Nemeth, et al. Peace. I think there's a text called Bugs and Daffy Go Filesystem Partitioning which might be a good place to start. : -- paul It's working as coded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Wed, 03 Dec 2003 12:04:22 -0800, Mark Ferlatte wrote: Paul Morgan said on Tue, Dec 02, 2003 at 07:33:27PM -0500: On Tue, 02 Dec 2003 14:20:05 -0800, Mark Ferlatte wrote: You demonstrate a minimal understanding of the purpose of partitioning, and, indeed, of the boot process. You are, of course, perfectly entitled to set up you system any way you wish. I have found you an argument; I am not obliged to find you an understanding. I am sorry that you felt a need to be offensive. If my questions offending, I apologize; they were intended to understand your point of view, not attack it. M Then we are both misunderstood; I felt that I wasn't really getting through to you and hoped to jog you into stopping and thinking. It was clumsy, and it certainly wasn't my intention to be offensive. On seeing your response, I read back through the thread and readily admit that I could have been more helpful, or, at least, more polite. In hindsight, Karsten wrote the reply that I should have written. I extend my sincere apology. -- paul I think that gay marriage is something that should be between a man and a woman. -- Arnold Schwarzenegger, Governor of California -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Fwd: Re: unchecked 31 times]
My apologies, Greg: I actually wanted to send this mail to the list, so with the private mail I accidentally sent you, you'll probably have it now a second time. Best Regards, Wolfgang -Forwarded Message- From: Wolfgang Pfeiffer [EMAIL PROTECTED] To: Greg Folkert [EMAIL PROTECTED] Subject: Re: unchecked 31 times Date: Tue, 02 Dec 2003 12:38:04 +0100 On Tue, 2003-12-02 at 00:19, Greg Folkert wrote: On Mon, 2003-12-01 at 16:20, Monique Y. Herman wrote: But just for the sake of argument, why do you say the root partition should be 200MB? root should only be enough to boot with... Currently on my system (I'm the only user of the machine) du -hc /folder/ gave me these space usages: /etc = 45MB (with GConf taking 30MB of that) 42M total /bin = 3.5MB 3.1Mtotal /sbin = 3MB 4.6Mtotal /lib = 35MB 58M total /dev = 128KB 40K total /root = 15MB or so 51M total /proc = null 2.8Mtotal/ or: 773M (seems to change from time to time) /tmp = 50K or so (not a separate filesystem until multi-user/services) 56K total All these values after about half a year since I installed the system ... currently with X, Gnome etc. ... and I hope I can use the machine for the next few years :) HTH ... Best Regards, Wolfgang / should equal the sum of them ~ 100MB. Adding for growth a bit... That is why I say 200MB. These should all be separate partitions/drive/mountpoints /usr /usr/local /var /home /tmp /boot (personal pref) That would keep your problems to a minimum. And keep your reboots to a minimum as well. -- Profile, Links: http://profiles.yahoo.com/wolfgangpfeiffer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Paul E Condon [EMAIL PROTECTED] writes: I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted file system? e.g. at 3am local time, or maybe 3pm for night owls? Or maybe while the machine is going down for the night? Jürgen -- Jürgen Stuber [EMAIL PROTECTED] http://www.loria.fr/~stuber/ GPG key fingerprint: 962F E883 D7B5 F8B6 11CC 4375 8014 62D6 5F17 ADD7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 22:12:59 -0500, Greg Folkert [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Mon, 2003-12-01 at 21:24, Monique Y. Herman wrote: On Tue, 02 Dec 2003 at 01:28 GMT, Greg Folkert penned: / and /var are machine critical. Let us remember I come from Huge Enterprise setups. Let's just suppose You are a developer writing a PL/SQL 300-way innerjoin. Those temporary files get written to /tmp. For those of us running non-huge-enterprise setups, the effort involved in having that many separate partitions/drives may not be worth it. I still split things up, but not as finely as you do. I call it habit, then. BUT, I also discover I can move things around migrating off a going bad disk much easier. Seldom do I lose things due to a bad disk... or even a bad kernel. Or a bad piece of hardware... So far, it has been fire at the company... and they didn't believe in Off-site storage because they had a fire-proof safe that could with stand 36 hours of 1400 Degree heat. Well it dunnah matter when you leave the SAFE DOOR OPEN But oh well... preferences are preferences. ..usually when Twin Hair's screw up this bad, their companies enter into the terminal dive into bankruptsy. You have new jobs waiting? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Tue, 02 Dec 2003 at 12:07 GMT, Juergen Stuber penned: Paul E Condon [EMAIL PROTECTED] writes: I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted file system? e.g. at 3am local time, or maybe 3pm for night owls? Or maybe while the machine is going down for the night? What's this, now? Machines don't need sleep! -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 21:41:21 -0500, Tom Vier wrote: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. With regard to lilo, your statement is incorrect. -- paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 15:39:16 -0800, Mark Ferlatte wrote: Greg Folkert said on Mon, Dec 01, 2003 at 06:19:12PM -0500: root should only be enough to boot with... /etc = 45MB (with GConf taking 30MB of that) /bin = 3.5MB /sbin = 3MB /lib = 35MB /dev = 128KB /root = 15MB or so /proc = null /tmp = 50K or so (not a separate filesystem until multi-user/services) / should equal the sum of them ~ 100MB. Adding for growth a bit... That is why I say 200MB. These should all be separate partitions/drive/mountpoints /usr /usr/local /var /home /tmp /boot (personal pref) There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? I'm just curious as to the reasoning behind your partitioning scheme. M FHS says The contents of the root filesystem should be adequate to boot, restore, recover, and/or repair the system. /tmp and /var/tmp have different purposes. Check FHS again. Actually, I have both /tmp and /var/tmp on their own logical volumes. -- paul Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know. - Donald Rumsfeld, US Secretary of Defense, Winner of British Plain English Campaign's 2003 Foot in Mouth award. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 22:35:09 -0500, charlie derr wrote: Monique Y. Herman wrote: On Tue, 02 Dec 2003 at 02:41 GMT, Tom Vier penned: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. Odd. I use lilo on unstable, and look at what mount says: /dev/hda1 on /boot type ext3 (rw) It occurred to me after posting almost the exact same response that probably Tom was referring to the case where / was either reiserfs or xfs or jfs, or... ~c He is still incorrect. My understanding is that lilo works off a system map which is created at installation and is sector based. So, as long as it can figure out where the kernel is physically placed at installation, it can map it. Then, when loading the kernel, it doesn't have to care about the filesystem. So the boot loader can be tiny. Grub is different. It has to grok the filesystem at boot time, so the boot loader is huge as a result. Oh, and lilo can boot off a RAID device. -- paul Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know. - Donald Rumsfeld, US Secretary of Defense, Winner of British Plain English Campaign's 2003 Foot in Mouth award. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Paul Morgan said on Tue, Dec 02, 2003 at 03:49:52PM -0500: There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? I'm just curious as to the reasoning behind your partitioning scheme. M FHS says The contents of the root filesystem should be adequate to boot, restore, recover, and/or repair the system. Right... so, again with the why put /usr on a seperate partition from /? Making / large enough to hold /usr certainly fulfills the req of the contents of the root filesystem being adequate to boot, restore, recover and repair the system. /tmp and /var/tmp have different purposes. Check FHS again. Actually, I have both /tmp and /var/tmp on their own logical volumes. Okay, so neither your /tmp or /var/tmp volumes are available at boot time. So, why have a seperate /tmp and /var/tmp? According to the FHS 2.2, the only difference between /tmp and /var/tmp is that data in /var/tmp be more persistant than data in /tmp, but the only restriction on /tmp is that programs not assume that data in /tmp persists between invocations of a program. In other words, /var/tmp appears to completely fulfill the requirements of /tmp, which makes me wonder why they are seperate. M pgp0.pgp Description: PGP signature
Re: unchecked 31 times
On Tue, 2003-12-02 at 17:20, Mark Ferlatte wrote: Paul Morgan said on Tue, Dec 02, 2003 at 03:49:52PM -0500: There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? I'm just curious as to the reasoning behind your partitioning scheme. M FHS says The contents of the root filesystem should be adequate to boot, restore, recover, and/or repair the system. Right... so, again with the why put /usr on a seperate partition from /? Making / large enough to hold /usr certainly fulfills the req of the contents of the root filesystem being adequate to boot, restore, recover and repair the system. /usr should NOT be needed to repair, recover, maintain, restore or boot. It goes against everything I have ever known about UNIX/Linux/*BSD. /tmp and /var/tmp have different purposes. Check FHS again. Actually, I have both /tmp and /var/tmp on their own logical volumes. Okay, so neither your /tmp or /var/tmp volumes are available at boot time. So, why have a seperate /tmp and /var/tmp? Because it allows you to keep systems over runs from disabling the machine. Ever tried to access a machine with a FULL / and/or /var? According to the FHS 2.2, the only difference between /tmp and /var/tmp is that data in /var/tmp be more persistant than data in /tmp, but the only restriction on /tmp is that programs not assume that data in /tmp persists between invocations of a program. In other words, /var/tmp appears to completely fulfill the requirements of /tmp, which makes me wonder why they are seperate. Because they are treated differently in practice... which allows something to store a map of stuff, or a session cache in /var/tmp and to use /tmp as a spillover area for temp data to be worked on. -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: unchecked 31 times
On Tue, 02 Dec 2003 14:20:05 -0800, Mark Ferlatte wrote: Paul Morgan said on Tue, Dec 02, 2003 at 03:49:52PM -0500: There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? I'm just curious as to the reasoning behind your partitioning scheme. M FHS says The contents of the root filesystem should be adequate to boot, restore, recover, and/or repair the system. Right... so, again with the why put /usr on a seperate partition from /? Making / large enough to hold /usr certainly fulfills the req of the contents of the root filesystem being adequate to boot, restore, recover and repair the system. /tmp and /var/tmp have different purposes. Check FHS again. Actually, I have both /tmp and /var/tmp on their own logical volumes. Okay, so neither your /tmp or /var/tmp volumes are available at boot time. So, why have a seperate /tmp and /var/tmp? According to the FHS 2.2, the only difference between /tmp and /var/tmp is that data in /var/tmp be more persistant than data in /tmp, but the only restriction on /tmp is that programs not assume that data in /tmp persists between invocations of a program. In other words, /var/tmp appears to completely fulfill the requirements of /tmp, which makes me wonder why they are seperate. M You demonstrate a minimal understanding of the purpose of partitioning, and, indeed, of the boot process. You are, of course, perfectly entitled to set up you system any way you wish. I have found you an argument; I am not obliged to find you an understanding. -- paul I think that gay marriage is something that should be between a man and a woman. -- Arnold Schwarzenegger, Governor of California -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. As the manpage says: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. Calm waters often conceal sharks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. As the manpage says: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, Dec 01, 2003 at 11:17:42AM -0700, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. As the manpage says: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted file system? e.g. at 3am local time, or maybe 3pm for night owls? -- Paul E Condon [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: unchecked 31 times
On Mon, 01 Dec 2003 11:17:42 -0700, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. As the manpage says: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? He didn't say he was running ext3. If he is, you're right. I tested ext3 when I moved to it by powering down my machine when several writes were going on. I never did break it. To be fair, I did the same kind of testing on WinXP's NTFS, and I didn't break that either. -- paul The average lifespan of a Web page today is 100 days. This is no way to run a culture. Internet Archive Board Chairman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Monique Y. Herman [EMAIL PROTECTED] writes: Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? It's a good thing to disable boot time fscks most of the time, because it speeds things up. (Journalling FSes can also prevent loss of data, which is why I use it.) But you don't want to disable _all_ checks, because a journaling fs won't protect you from your hard drive slowing breaking, or kernel bugs subtly messing up the filesystem, or some other problems. So it's in your best interest to wait through a long boot fsck once in a while, just in case it finds problems before they get out of hand. -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. Roman Catholic: The world's oldest and largest franchise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 at 18:53 GMT, Paul E Condon penned: =20 Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? =20 I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted=20 file system? e.g. at 3am local time, or maybe 3pm for night owls? Wouldn't this require rebooting first, or something, in order to fsck the root partition? -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 11:53:26 -0700, Paul E Condon wrote: I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted file system? e.g. at 3am local time, or maybe 3pm for night owls? cron -- paul The average lifespan of a Web page today is 100 days. This is no way to run a culture. Internet Archive Board Chairman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Monique Y. Herman [EMAIL PROTECTED] writes: On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? The relevant perk is that, if the system shuts down abnormally, the boot-time fsck gets to replay the journal, which is fast, rather than actually having to go through and do the full check. If you have bad hardware, no filesystem is going to be completely safe against random lossage; running periodic full fscks just in case is good practice. (But turning the check frequency down is almost certainly a practical thing to do.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 at 19:00 GMT, Paul Morgan penned: On Mon, 01 Dec 2003 11:17:42 -0700, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. As the manpage says: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? He didn't say he was running ext3. If he is, you're right. I tested ext3 when I moved to it by powering down my machine when several writes were going on. I never did break it. Is it just ext3, or do all journalling file systems obviate the need for fsck? IIRC, ext3 is slower than the other options because it has a more complete journal ... but I may be totally wrong. Just to be a pain, I might point out that just because you never broke it during those tests, doesn't mean that such a test couldn't break it. To be fair, I did the same kind of testing on WinXP's NTFS, and I didn't break that either. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Hello Paul! On Mon, Dec 01, 2003 at 11:53:26AM -0700, Paul E Condon wrote: I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted file system? e.g. at 3am local time, or maybe 3pm for night owls? Sort of difficult as the filesystem must be unmounted for a fsck, just as you say, so at least / is out. For / you can schedule a fsck for next reboot by creating a file /forcefsck, see /etc/init.d/check* for further hints. This is even recommendable every once a while. Otherwise you can maybe do some scripting to umount the filesystem, if possible, fsck it, and remount again, but I personally prefer a reboot for clean checking, as I like to keep an eye on it... Cheers, Flo pgp0.pgp Description: PGP signature
Re: unchecked 31 times
On Mon, Dec 01, 2003 at 12:10:36PM -0700, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 18:53 GMT, Paul E Condon penned: =20 Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? =20 I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted=20 file system? e.g. at 3am local time, or maybe 3pm for night owls? Wouldn't this require rebooting first, or something, in order to fsck the root partition? Maybe not, if one can figure out how to start a ramdisk OS dynamically, or some such. I didn't say it would be easy. I think I will have *a lot* of respect for whoever does figure it out, but I don't think its impossible. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 2003-12-01 at 14:10, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 18:53 GMT, Paul E Condon penned: =20 Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? =20 I guess there's no free lunch. But is there some way to schedule fsck at some regular time when you know you won't be needing the mounted=20 file system? e.g. at 3am local time, or maybe 3pm for night owls? Wouldn't this require rebooting first, or something, in order to fsck the root partition? the root partition should be small anyway. 200MB or so. Those that have one single 200GB root partition are asking for trouble... I have all of my home machine and work machine storing critical data on an NFS or samba mounted arrays. So sure go ahead and blowup the local disk on the workstations... not matter all fun stuff is saved on my backed-up nfs/samba server. It is still just good practice to not have a HUGE root partition. Heck use LVM anyway... that is what it is for. Dynamically modify your filesystems. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: unchecked 31 times
On Mon, 2003-12-01 at 14:33, David Z Maze wrote: Monique Y. Herman [EMAIL PROTECTED] writes: On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? The relevant perk is that, if the system shuts down abnormally, the boot-time fsck gets to replay the journal, which is fast, rather than actually having to go through and do the full check. If you have bad hardware, no filesystem is going to be completely safe against random lossage; running periodic full fscks just in case is good practice. (But turning the check frequency down is almost certainly a practical thing to do.) I usually have it check based on time since last check... problem is most of my machine stay up for hundreds of days at a time... so it means a full-fsck every boot. If I did number mounts... it could be YEARS, maybe even a decade between checks. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: unchecked 31 times
On Mon, 01 Dec 2003 12:23:10 -0700, Monique Y. Herman wrote: Is it just ext3, or do all journalling file systems obviate the need for fsck? IIRC, ext3 is slower than the other options because it has a more complete journal ... but I may be totally wrong. Just to be a pain, I might point out that just because you never broke it during those tests, doesn't mean that such a test couldn't break it. Yes, I didn't guarantee that it was unbreakable, just observed that my fairly brutal tests didn't break it. I don't know about the other filesystems, I only use ext3. -- paul The average lifespan of a Web page today is 100 days. This is no way to run a culture. Internet Archive Board Chairman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 at 20:29 GMT, Greg Folkert penned: =20 =20 Wouldn't this require rebooting first, or something, in order to fsck the root partition? the root partition should be small anyway. 200MB or so. Those that have one single 200GB root partition are asking for trouble... That's not really the point. I think the point is that most of us try to *avoid* reboots whenever possible ... But just for the sake of argument, why do you say the root partition should be 200MB? I have all of my home machine and work machine storing critical data on an NFS or samba mounted arrays. So sure go ahead and blowup the local disk on the workstations... not matter all fun stuff is saved on my backed-up nfs/samba server. And I back up the important stuff to an external drive. That doesn't mean I don't want to know about problems before the excrement hits the fan ... It is still just good practice to not have a HUGE root partition. Heck use LVM anyway... that is what it is for. Dynamically modify your filesystems. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 2003-12-01 at 16:20, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 20:29 GMT, Greg Folkert penned: =20 =20 Wouldn't this require rebooting first, or something, in order to fsck the root partition? the root partition should be small anyway. 200MB or so. Those that have one single 200GB root partition are asking for trouble... That's not really the point. I think the point is that most of us try to *avoid* reboots whenever possible ... But just for the sake of argument, why do you say the root partition should be 200MB? root should only be enough to boot with... /etc = 45MB (with GConf taking 30MB of that) /bin = 3.5MB /sbin = 3MB /lib = 35MB /dev = 128KB /root = 15MB or so /proc = null /tmp = 50K or so (not a separate filesystem until multi-user/services) / should equal the sum of them ~ 100MB. Adding for growth a bit... That is why I say 200MB. These should all be separate partitions/drive/mountpoints /usr /usr/local /var /home /tmp /boot (personal pref) That would keep your problems to a minimum. And keep your reboots to a minimum as well. -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: unchecked 31 times
Greg Folkert said on Mon, Dec 01, 2003 at 06:19:12PM -0500: root should only be enough to boot with... /etc = 45MB (with GConf taking 30MB of that) /bin = 3.5MB /sbin = 3MB /lib = 35MB /dev = 128KB /root = 15MB or so /proc = null /tmp = 50K or so (not a separate filesystem until multi-user/services) / should equal the sum of them ~ 100MB. Adding for growth a bit... That is why I say 200MB. These should all be separate partitions/drive/mountpoints /usr /usr/local /var /home /tmp /boot (personal pref) There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? I'm just curious as to the reasoning behind your partitioning scheme. M pgp0.pgp Description: PGP signature
Re: unchecked 31 times
- Original Message - From: Monique Y. Herman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 01, 2003 13:23 Subject: Re: unchecked 31 times On Mon, 01 Dec 2003 at 19:00 GMT, Paul Morgan penned: On Mon, 01 Dec 2003 11:17:42 -0700, Monique Y. Herman wrote: On Mon, 01 Dec 2003 at 16:55 GMT, Alan Shutko penned: Nick Welch [EMAIL PROTECTED] writes: I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 That's a very bad idea. As the manpage says: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Wait, wait; I'm confused. I thought one of the perks of running a journalling file system was that you can speed up the boot process by disabling boot-time fsck? He didn't say he was running ext3. If he is, you're right. I tested ext3 when I moved to it by powering down my machine when several writes were going on. I never did break it. Is it just ext3, or do all journalling file systems obviate the need for fsck? IIRC, ext3 is slower than the other options because it has a more complete journal ... but I may be totally wrong. Just to be a pain, I might point out that just because you never broke it during those tests, doesn't mean that such a test couldn't break it. To be fair, I did the same kind of testing on WinXP's NTFS, and I didn't break that either. -- monique My system runs fsck after 37 mounts without a filesystem check. Thanks monique for removing your previous sig. It made me want to CC you. Hoyt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 2003-12-01 at 18:39, Mark Ferlatte wrote: Greg Folkert said on Mon, Dec 01, 2003 at 06:19:12PM -0500: root should only be enough to boot with... /etc = 45MB (with GConf taking 30MB of that) /bin = 3.5MB /sbin = 3MB /lib = 35MB /dev = 128KB /root = 15MB or so /proc = null /tmp = 50K or so (not a separate filesystem until multi-user/services) / should equal the sum of them ~ 100MB. Adding for growth a bit... That is why I say 200MB. These should all be separate partitions/drive/mountpoints /usr /usr/local /var /home /tmp /boot (personal pref) There are currently Debian packages which are needed at boot time which depend upon datafiles kept in /usr. discover is one of them, there may be more. In woody, therefor, a seperate /usr can cause problems. Does it gain you much? You see, I have always had a separate /usr... never seen a problem yet. Booting into S doesn't do the data discovery. That is what I am getting at. S or 1 is maintenance mode. Everything you need to maintain the boxen should be on / and that is all it should have. I come from very heavy duty system, that they would get everything except the root filesystem blotched out. Get massive upgrades HOT and then I'd have to restore the filesystems. If I did not have everything I needed to restore from a Remote Tape-Library... I was fscked. These machine sometimes took hours to come up, with 32 Processors and 32GB of Memory, Multiple Multi-terabyte filesystems (All with journal-ling) Everything I needed was on /. Plus I could make a bootable tape or a bootable CD or bootable DVD and still be inside (usually with frillz added because I had room) 250MB. This was on AIX, HPUX, TRU64 (OSF/1), etc... So, now you understand why I always suggest 200MB(okay I have a 300MB / filesystem). Why should /tmp be its own partition instead of symlinking /tmp - /var/tmp? / and /var are machine critical. Let us remember I come from Huge Enterprise setups. Let's just suppose You are a developer writing a PL/SQL 300-way innerjoin. Those temporary files get written to /tmp. With /tmp on root filesystem... oops there goes the machine With /tmp on /var all logging goes away... among other things. With /tmp its own filesystem... the PL/SQL fails YEAH that's what you want. Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? Yes. Simplicity. I use grub as a boot-loader. My workstation menu.lst looks like: --- timeout=5 default=0 fallback=1 root(hd0,0) title 2.6.0-test9-20031123-k7 kernel /vmlinuz-2.6.0-test9-20031123-k7 ro root=/dev/hde2 initrd /initrd.img-2.6.0-test9-20031123-k7 title 2.4.22-20031108-k7 kernel /vmlinuz-2.4.22-20031108-k7 vga=791 ro root=/dev/hde2 initrd /initrd.img-2.4.22-20031108-k7 title 2.6.0-test9-1-386 kernel /vmlinuz-2.6.0-test9-1-386 ro root=/dev/hde2 initrd /initrd.img-2.6.0-test9-1-386 title 2.4.22-1-k7 kernel /vmlinuz-2.4.22-1-k7 vga=791 ro root=/dev/hde2 initrd /initrd.img-2.4.22-1-k7 title 2.4.21-20031012-k7 kernel /vmlinuz-2.4.21-20031012-k7 vga=791 ro root=/dev/hde2 initrd /initrd.img-2.4.21-20031012-k7 title 2.4.21-5-k7 kernel /vmlinuz-2.4.21-5-k7 vga=791 ro root=/dev/hde2 initrd /initrd.img-2.4.21-5-k7 --- If I had it included in / I'd have to add /boot to the front of every line. Plus it keeps me from having t many kernels installed, plus I can make it read-only making it more difficult to change. I'm just curious as to the reasoning behind your partitioning scheme. It's fine... I have used spreadsheets to map out things and I never have come up with the perfect setup. Close... but not poifec -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: unchecked 31 times
On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0xE6CB97DA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Tue, 02 Dec 2003 at 01:28 GMT, Greg Folkert penned: / and /var are machine critical. Let us remember I come from Huge Enterprise setups. Let's just suppose You are a developer writing a PL/SQL 300-way innerjoin. Those temporary files get written to /tmp. For those of us running non-huge-enterprise setups, the effort involved in having that many separate partitions/drives may not be worth it. I still split things up, but not as finely as you do. -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 01 Dec 2003 at 23:17 GMT, Hoyt Bailey penned: My system runs fsck after 37 mounts without a filesystem check. Thanks monique for removing your previous sig. It made me want to CC you. Hoyt =P -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Tom Vier wrote: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. I don't think this is completely true. I'm using lilo and / is ext3 (i have no separate /boot partition). ~c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, 2003-12-01 at 21:24, Monique Y. Herman wrote: On Tue, 02 Dec 2003 at 01:28 GMT, Greg Folkert penned: / and /var are machine critical. Let us remember I come from Huge Enterprise setups. Let's just suppose You are a developer writing a PL/SQL 300-way innerjoin. Those temporary files get written to /tmp. For those of us running non-huge-enterprise setups, the effort involved in having that many separate partitions/drives may not be worth it. I still split things up, but not as finely as you do. I call it habit, then. BUT, I also discover I can move things around migrating off a going bad disk much easier. Seldom do I lose things due to a bad disk... or even a bad kernel. Or a bad piece of hardware... So far, it has been fire at the company... and they didn't believe in Off-site storage because they had a fire-proof safe that could with stand 36 hours of 1400 Degree heat. Well it dunnah matter when you leave the SAFE DOOR OPEN But oh well... preferences are preferences. -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry signature.asc Description: This is a digitally signed message part
Re: unchecked 31 times
On Tue, 02 Dec 2003 at 02:41 GMT, Tom Vier penned: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. Odd. I use lilo on unstable, and look at what mount says: /dev/hda1 on /boot type ext3 (rw) -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Monique Y. Herman wrote: On Tue, 02 Dec 2003 at 02:41 GMT, Tom Vier penned: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: Is there any need for a /boot partition on modern hardware? Why do you like a seperate boot partition? yes, many bootloaders (aboot, silo, lilo) can only read ext2. Odd. I use lilo on unstable, and look at what mount says: /dev/hda1 on /boot type ext3 (rw) It occurred to me after posting almost the exact same response that probably Tom was referring to the case where / was either reiserfs or xfs or jfs, or... ~c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Mon, Dec 01, 2003 at 09:59:18PM -0500, charlie derr wrote: Tom Vier wrote: On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote: yes, many bootloaders (aboot, silo, lilo) can only read ext2. I don't think this is completely true. I'm using lilo and / is ext3 (i have no separate /boot partition). Any ext3 filesystem can be mounted without journaling as ext2. -- Nick Welch aka mackstann | mack @ incise.org | http://incise.org Help me, I'm a prisoner in a Fortune cookie file! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
Tom Vier said on Mon, Dec 01, 2003 at 09:41:21PM -0500:
On Mon, Dec 01, 2003 at 03:39:16PM -0800, Mark Ferlatte wrote:
Is there any need for a /boot partition on modern hardware? Why do you like a
seperate boot partition?
yes, many bootloaders (aboot, silo, lilo) can only read ext2.
I use lilo and reiserfs on / and it works just fine. AFAIK, grub also works
with reiserfs and xfs, in addition to ext{2,3}.
M
pgp0.pgp
Description: PGP signature
Re: unchecked 31 times
Hello Mark!
On Mon, Dec 01, 2003 at 08:34:39PM -0800, Mark Ferlatte wrote:
I use lilo and reiserfs on / and it works just fine. AFAIK, grub also works
with reiserfs and xfs, in addition to ext{2,3}.
From the grub manual:
|The currently supported filesystem types are BSD FFS, DOS FAT16 and
|FAT32, Minix fs, Linux ext2fs, ReiserFS, JFS, XFS, and VSTa fs.
As ext3 can be read as ext2 grub also supports reading it.
Cheers,
Flo
pgp0.pgp
Description: PGP signature
Re: unchecked 31 times
Hi That's not really a problem. The system does run the check programs (e2fsck etc.) on every startup. These programs mainly check, if the partition was umounted correctly. If there was a correct umount they increase the mount counter, if not they check the full prtition and reset the counter to 0. If the partition was mounted coorectly a fixed amount (in the normal case 31 / ~ month), the programs force a check, and reset the counter to 0. I think all Linux distributions do something like that and don't enforce a full check on bootup. So no problem with unchecked partitions. ATB Jan-Marek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Sun, Nov 30, 2003 at 11:21:11AM +0530, Joydeep Bakshi wrote: hre is a typical prob in debian. after particular days my debian show during booting * /dev/hda6 mounted 31 times without checking, check forcde* and it starts fsck. now my question is that has debian programmed to check hard disk after 31 times mounting the disk ? if so how to change this so that it will check hard disk whenever find a problem like red-hat ? I suppose mke2fs(8) is where that comes from specifically. Easy to disable the periodic checks, though: tune2fs -i 0 -c 0 /dev/hda6 -- Nick Welch aka mackstann | mack @ incise.org | http://incise.org Life would be so much easier if we could just look at the source code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unchecked 31 times
On Sun, Nov 30, 2003 at 11:21:11AM +0530, Joydeep Bakshi wrote: Hi list, hre is a typical prob in debian. after particular days my debian show during booting * /dev/hda6 mounted 31 times without checking, check forcde* and it starts fsck. now my question is that has debian programmed to check hard disk after 31 times mounting the disk ? if so how to change this so that it will check hard disk whenever find a problem like red-hat ? thanks in advanced. PS: please cc to me Hi, You can change this behaviour by using tune2fs. Have a look at the -c and -i option, and make sure you _really_ want to do this. Cheers, Pasc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
