The problem with bad sectors is not with sectors that show a write check but with those that don't show a write check but are bad. The write check on most hard drives is very simple and consists only of parity. If a certain number of bits are dropped then there will be no write check and install will work perfectly. You will never know about this until you try to run the program because there will be no read error. In addition there is the case where buffers are being allocated. No check of media integrity is made on these(swap partition). This has always been a problem with RH. Most shops have discs with small bad spots and many discs develop these over time. The c option was put into mkfs just to take care of these problems. At the present time we must take ANY disc that displays even a small bad spot and use mkfs on another system before we can install Linux. I suspect that a surprising number of the strange troubles that are being reported by only one user are due to this problem. When you invoke Disc Druid you need to be able to request a long format or else mkfs needs to be on the recovery disc. Currently discs are tested at the factory and bad sectors are locked out In some large discs there are quite a few bad spots. In normal operation perfectly good discs will have bad spots develop over time. This is not a serious problem with modern discs if it is handled by the software. The problem has always been that RH doesn't handle the problem. Incidently, Microsoft does.
On Fri, 2004-12-17 at 10:05 -0500, gslink wrote:
The problem with bad sectors is not with sectors that show a write check but with those that don't show a write check but are bad. The write check on most hard drives is very simple and consists only of parity.
actually it's a far more sophisticated ECC like code that even allows single bit errors to be automatically corrected.
And disks do constant "signal strength" measurements and such and relocate sectors before things go bad.
Remember that before using a sector on a new partition, you *always* write to it (in a filesystem at least), and that's where the bad situation will be detected *and remapped*.
If your disk is beyond remapping, the smart daemon (on by default) will send you a nice mail saying that your disk is going bad.
On Fri, 17 Dec 2004 16:26:46 +0100, Arjan van de Ven arjanv@redhat.com wrote:
If your disk is beyond remapping, the smart daemon (on by default) will send you a nice mail saying that your disk is going bad.
This is a good reason I'd like to see trying to move towards a rootless install with an sudo-like controlled administrator. I'm not sure how many users, especially the first time users, know about the sorts of emails like smart's that can be sent to root user. It would be really keen if these sorts of mails could be sent to a normal user account in home lan situations without the user even knowing that smart is actually there and needs to be reconfigured to send mail to non-root. Also is this sort of thing a candidate for the mystical 'notification bubbles' concept?
-jef
On Fri, Dec 17, 2004 at 05:41:42PM -0500, Jeff Spaleta wrote:
I'm not sure how many users, especially the first time users, know about the sorts of emails like smart's that can be sent to root user.
In /etc/aliases you probably have lines like that:
# Person who should get root's mail #root: marc
Maybe install should ask data for this alias and fill that lines unless specifically and emphatically declined? The big advantage is that this solves the issue in a general way instead for some specific cases like smart.
Michal
On 12/17/2004 05:56:34 PM, Michal Jaegermann wrote:
On Fri, Dec 17, 2004 at 05:41:42PM -0500, Jeff Spaleta wrote:
I'm not sure how many users, especially the first time users, know about the sorts of emails like smart's that can be sent to root user.
In /etc/aliases you probably have lines like that:
# Person who should get root's mail #root: marc
Maybe install should ask data for this alias and fill that lines unless specifically and emphatically declined? The big advantage is that this solves the issue in a general way instead for some specific cases like smart.
Firstboot creates an ordinary user for the person doing the install (sysadmin or sole user) - it would be useful if that user were to receive root's mail.
Regards, Willem Riede.
On Fri, Dec 17, 2004 at 03:56:34PM -0700, Michal Jaegermann wrote:
In /etc/aliases you probably have lines like that:
# Person who should get root's mail #root: marc
Maybe install should ask data for this alias and fill that lines unless specifically and emphatically declined? The big advantage is that this solves the issue in a general way instead for some specific cases like smart.
Yes, it'd be nice if firstboot or the installer could do this. However, I highly, highly recommend not trying to have some program manage (or mangle!) entries in /etc/aliases. Instead:
root: :include: /etc/rootalias
and then have the program drop root aliases into its own clean, separate file.
For BU Linux, this is exactly what we do, and then we have a script which (unless configured differently in "/etc/sysconfig/rootalias-manager") adds members of the wheel group to this alias automatically.
Later today, I'll file a bug making the small /etc/rootalias recommendation as a first step.
On Mon, Dec 20, 2004 at 11:15:04AM -0500, Matthew Miller wrote:
Yes, it'd be nice if firstboot or the installer could do this. However, I highly, highly recommend not trying to have some program manage (or mangle!) entries in /etc/aliases. Instead:
root: :include: /etc/rootalias
and then have the program drop root aliases into its own clean, separate file.
I would prefer
root: :include: /etc/mail/rootalias
or maybe
root: :include: /etc/sysconfig/rootalias
(and things like a silent skip if that alias is already defined) but we are arguing here about details of an implementation.
I think that there is a general agreement that something of that sort would be highly desirable. Should there be a bugzilla RFE for that?
Michal
On Mon, Dec 20, 2004 at 12:28:32PM -0700, Michal Jaegermann wrote:
I would prefer root: :include: /etc/mail/rootalias
Maybe. Postfix doesn't use this directory. Nor does exim. On the other hand, spamassassin puts its files there, so there's some non-sendmail-specific precedent. I understand the desire to not clutter up /etc further.
or maybe root: :include: /etc/sysconfig/rootalias
I don't think this is good, because almost everything else in /etc/sysconfig is either actually sourced into a shell script or sets variables in a format that looks like that ("FOO=bar").
(and things like a silent skip if that alias is already defined) but we are arguing here about details of an implementation. I think that there is a general agreement that something of that sort would be highly desirable. Should there be a bugzilla RFE for that?
Yes, there should. :)
https://bugzilla.redhat.com/beta/show_bug.cgi?id=143437
On Mon, Dec 20, 2004 at 03:10:36PM -0500, Matthew Miller wrote:
On Mon, Dec 20, 2004 at 12:28:32PM -0700, Michal Jaegermann wrote:
I would prefer root: :include: /etc/mail/rootalias
Maybe. Postfix doesn't use this directory. Nor does exim.
If these MTAs understand 'include:' in aliases then it does not matter as you have a full path. I simply do not like everything on the first level of /etc/.
Thanks.
Michal
On Mon, Dec 20, 2004 at 03:02:38PM -0700, Michal Jaegermann wrote:
I would prefer root: :include: /etc/mail/rootalias
Maybe. Postfix doesn't use this directory. Nor does exim.
If these MTAs understand 'include:' in aliases then it does not matter as you have a full path. I simply do not like everything on the first level of /etc/.
I know; I just meant, they don't put stuff there. It's kinda sendmail's directory, despite the generic name.
On Fri, 17 Dec 2004, Jeff Spaleta wrote:
be really keen if these sorts of mails could be sent to a normal user account in home lan situations without the user even knowing that smart is actually there and needs to be reconfigured to send mail to non-root.
Even better, and a lot more 'doable' would be for firstboot to provide a simple one click option to direct root's mail to the user account it creates. Then smart, mdadm, cron, etc could continue sending mail to root and it would end up in the primary user's mailbox without the user needing to understand the gory details or each package needing to be smarter.
On Mon, 20 Dec 2004 13:28:03 -0600 (CST), John Morris jmorris@beau.org wrote:
Then smart, mdadm, cron, etc could continue sending mail to root and it would end up in the primary user's mailbox without the user needing to understand the gory details or each package needing to be smarter.
I don't think i was advocating that each package become invidually smarter. Effective redirection of notification emails to an administrative user is just one aspect of the larger problem in defining an administrative user role instead of relying on people to use root user. There is a larger discussion about pre-configuring sudo for an adminstrative role for tasks instead of using a root user password that i was hoping to inspire. Sadly people actually wanted to solve this email problem and came up with a targetted solution.
-jef
On Mon, Dec 20, 2004 at 02:44:04PM -0500, Jeff Spaleta wrote:
There is a larger discussion about pre-configuring sudo for an adminstrative role for tasks instead of using a root user password that i was hoping to inspire. Sadly people actually wanted to solve this email problem and came up with a targetted solution.
How these two issues are tied up? Somewhat related in a general sense, agreed, but using sudo for email does not strike me as a particularly good idea.
Michal
fre, 17.12.2004 kl. 16.26 skrev Arjan van de Ven:
On Fri, 2004-12-17 at 10:05 -0500, gslink wrote:
The problem with bad sectors is not with sectors that show a write check but with those that don't show a write check but are bad. The write check on most hard drives is very simple and consists only of parity.
actually it's a far more sophisticated ECC like code that even allows single bit errors to be automatically corrected.
And disks do constant "signal strength" measurements and such and relocate sectors before things go bad.
Remember that before using a sector on a new partition, you *always* write to it (in a filesystem at least), and that's where the bad situation will be detected *and remapped*.
If your disk is beyond remapping, the smart daemon (on by default) will send you a nice mail saying that your disk is going bad.
Very, VERY many people never touches root's mail command...
On Fri, Dec 17, 2004 at 11:47:22PM +0100, Kyrre Ness Sjobak wrote:
If your disk is beyond remapping, the smart daemon (on by default) will send you a nice mail saying that your disk is going bad.
Very, VERY many people never touches root's mail command...
Indeed but at the moment the toolbar just has a 30Mb pointless up2date icon on it. Probably that needs to be 29Mb smaller and indicate other useful things
On Sun, 19 Dec 2004 11:01:37 -0500, Alan Cox alan@redhat.com wrote:
On Fri, Dec 17, 2004 at 11:47:22PM +0100, Kyrre Ness Sjobak wrote:
If your disk is beyond remapping, the smart daemon (on by default) will send you a nice mail saying that your disk is going bad.
Very, VERY many people never touches root's mail command...
Indeed but at the moment the toolbar just has a 30Mb pointless up2date icon on it. Probably that needs to be 29Mb smaller and indicate other useful things
Amen. We have to remove this from most of our workstations because it is completely meaningless and even the people who have 4 Gigabytes of RAM in their workstations thinks that 30MB is a waste for a dummy light.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
søn, 19.12.2004 kl. 17.54 skrev Stephen J. Smoogen:
On Sun, 19 Dec 2004 11:01:37 -0500, Alan Cox alan@redhat.com wrote:
On Fri, Dec 17, 2004 at 11:47:22PM +0100, Kyrre Ness Sjobak wrote:
If your disk is beyond remapping, the smart daemon (on by default) will send you a nice mail saying that your disk is going bad.
Very, VERY many people never touches root's mail command...
Indeed but at the moment the toolbar just has a 30Mb pointless up2date icon on it. Probably that needs to be 29Mb smaller and indicate other useful things
Amen. We have to remove this from most of our workstations because it is completely meaningless and even the people who have 4 Gigabytes of RAM in their workstations thinks that 30MB is a waste for a dummy light.
30 MB RAM?!? Could that be why 128 MB machines are so *DAMN* slow?
...
Urk. It's not like we use up2date anyway... I see a networkwide rpm -e up2date...
On Sun, 2004-12-19 at 11:01 -0500, Alan Cox wrote:
Indeed but at the moment the toolbar just has a 30Mb pointless up2date icon on it. Probably that needs to be 29Mb smaller and indicate other useful things
On my FC3 system, the rhn-applet is slightly less than 1MB. I don't understand the reference to 30MB...?
Cheers,
On Jan 4, 2005, "Rodolfo J. Paiz" rpaiz@simpaticus.com wrote:
On my FC3 system, the rhn-applet is slightly less than 1MB. I don't understand the reference to 30MB...?
I guess it may depend on the number of packages you have installed, the number of repositories listed in your up2date sources file, and maybe more.
On Tue, Jan 04, 2005 at 05:45:24PM -0200, Alexandre Oliva wrote:
On Jan 4, 2005, "Rodolfo J. Paiz" rpaiz@simpaticus.com wrote:
On my FC3 system, the rhn-applet is slightly less than 1MB. I don't understand the reference to 30MB...?
I guess it may depend on the number of packages you have installed, the number of repositories listed in your up2date sources file, and maybe more.
It also seems to grow over time, suggesting its leaking.
Dave
What you say is only partly true. Most discs do not relocate anything. This is especially true of older discs. I have a stack of discs that have small bad spots and must be formatted and sectors locked out before installing RH. As far as I can see this is simply a flaw that gives Microsoft an enormous club to use on Red Hat.
On Fri, Dec 17, 2004 at 10:05:15AM -0500, gslink wrote:
The problem with bad sectors is not with sectors that show a write check but with those that don't show a write check but are bad. The write
There is no way to detect disk errors of this form. Nor do we need to because the drive will do sparing for us
check on most hard drives is very simple and consists only of parity.
Wrong. The check on any modern drive is built around very complex mathematics because the bit density is so high that the data is always full of errors. Advanced FEC algorithms are used which can not only analyse the data and recover it from the noise but also assess how close to unreadable the block is and can then rewrite the block and if that fails move it. IDE disks also pretty much ignore "format" and "verify" commands except for reading each disk sector and checking if it seems acceptable.
If most of the disks you get have bad spots find a proper supplier. I've only seen that occur when people are not shipping drives properly (so the get damaged in transit) or if the vendor is recycling RMA'd drive pulls on the quiet.
Out of the box drives don't come with errors and haven't seen the days of EIDE.
Alan
Linux works very well with disc sizes of less than 1g. There are lots of these older discs around and if you want to make a firewall or other application which doesn't require lots of disc then these are excellent. If you are planning to use a large server then a new disc is a must. As I have said before older discs don't have the checks that modern discs have. There are even modern 20g drives that require you to lockout bad sectors.
On Tue, Dec 21, 2004 at 11:56:57AM -0500, gslink wrote:
Linux works very well with disc sizes of less than 1g. There are lots of these older discs around and if you want to make a firewall or other application which doesn't require lots of disc then these are excellent.
The era of disks that didn't always deal with bad blocks is well before drives hit the enormous inconceivable capacity of 1Gb.
If you are planning to use a large server then a new disc is a must. As I have said before older discs don't have the checks that modern discs have. There are even modern 20g drives that require you to lockout bad sectors.
Only faulty ones. And if they happen to be IBM/Hitachi then you should get the firmware updates for the "deathstar" drives applied if relevant.
Alan
-
Alan Cox -
Alexandre Oliva -
Arjan van de Ven -
Dave Jones -
gslink -
Jef Spaleta -
John Morris -
Kyrre Ness Sjobak -
Matthew Miller -
Michal Jaegermann -
Rodolfo J. Paiz -
Stephen John Smoogen -
Willem Riede