[opensuse-factory] enable smartd by default, reporting?
Hi, After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Ludwig Nussel
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08.10.2014 11:50, Guido Berhoerster wrote:
I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.
Sounds like exactly what I would like to have, too :) You don't happen to have dummie's instructions somewhere, do you? -- Vahis -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Vahis
On 08.10.2014 11:50, Guido Berhoerster wrote:
I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.
Sounds like exactly what I would like to have, too :)
You don't happen to have dummie's instructions somewhere, do you?
Well, it's rather simple. Put the following line in /etc/smartd.conf: DEVICESCAN -d removable -m <nomailer> -M exec /usr/local/lib/smartd_wall.sh Then create /usr/local/lib/smartd_wall.sh and make it executable: ----8<---- #!/bin/sh export PATH=/bin:/sbin:/usr/bin:/usr/sbin printf "%s\n" "${SMARTD_MESSAGE}" | wall -n ---->8---- If you're running KDE that's all you have to do, otherwise you need to download and install https://hg.guido-berhoerster.org/projects/xwrited/archive/tip.tar.bz2 or wait until I package it in home:gberh/xwrited later. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08.10.2014 13:12, Guido Berhoerster wrote:
* Vahis
[2014-10-08 11:24]: On 08.10.2014 11:50, Guido Berhoerster wrote:
I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.
Sounds like exactly what I would like to have, too :)
You don't happen to have dummie's instructions somewhere, do you?
Well, it's rather simple. Put the following line in /etc/smartd.conf: DEVICESCAN -d removable -m <nomailer> -M exec /usr/local/lib/smartd_wall.sh
Then create /usr/local/lib/smartd_wall.sh and make it executable: ----8<---- #!/bin/sh
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
printf "%s\n" "${SMARTD_MESSAGE}" | wall -n ---->8----
If you're running KDE that's all you have to do, otherwise you need to download and install https://hg.guido-berhoerster.org/projects/xwrited/archive/tip.tar.bz2 or wait until I package it in home:gberh/xwrited later.
Thanks! Now I just hope no broadcasts will ever occur... :) -- Vahis -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 8, 2014 at 6:24 AM, Vahis
On 08.10.2014 11:50, Guido Berhoerster wrote:
I have smartd configured to execute a script that creates a warning message via wall(1) and I think that's a pretty robust solution. It will generate a message on every console a user is logged in (in case he isn't using X), on every terminal emulator, and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.
Sounds like exactly what I would like to have, too :)
You don't happen to have dummie's instructions somewhere, do you?
You can configure a mail script for smartd with -w path, and that can be useful. The default script at /etc/smartd_warning.sh also doesn't do much more than sending an email, it can be useful to extend it to also wall. I'd go for the second option (extending smartd_warning.sh) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-10-08 10:50, Guido Berhoerster wrote:
I have smartd configured to execute a script that creates a warning message via wall(1) [...] and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.
Hm, I am using notify-send (not for SMART, but something else), might be the more portable solution? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Jan Engelhardt
On Wednesday 2014-10-08 10:50, Guido Berhoerster wrote:
I have smartd configured to execute a script that creates a warning message via wall(1) [...] and a desktop notification via kwrited on KDE or xwrited on Xfce/GNOME/LXDE.
Hm, I am using notify-send (not for SMART, but something else), might be the more portable solution?
I don't think so, notify-send requires access to each user's session DBus instance and you have to resort to some pretty gross and fragile hack to do that. In addition you don't reach users which are just logged in on a console. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-10-08 12:18, Guido Berhoerster wrote:
Hm, I am using notify-send (not for SMART, but something else), might be the more portable solution?
I don't think so, notify-send requires access to each user's session DBus instance and you have to resort to some pretty gross and fragile hack to do that. In addition you don't reach users which are just logged in on a console.
Shouldn't user sessions (ideally) also listen to the system bus to receive exactly this kind of user-unspecific system events? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Jan Engelhardt
On Wednesday 2014-10-08 12:18, Guido Berhoerster wrote:
Hm, I am using notify-send (not for SMART, but something else), might be the more portable solution?
I don't think so, notify-send requires access to each user's session DBus instance and you have to resort to some pretty gross and fragile hack to do that. In addition you don't reach users which are just logged in on a console.
Shouldn't user sessions (ideally) also listen to the system bus to receive exactly this kind of user-unspecific system events?
Sure, bute then you need just another daemon which subscribes to certain DBus signals by an emitter on the system bus and in turn invokes a method on the users notification daemon via the session bus. That's how gnome-disk-utility works. Basically udisks2 regularly polls SMART data and emits a signal via the system bus to which gnome-disk-utility instances running in the users sessions are subscribed and in turn create notifications over the session bus. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 08 octobre 2014 à 10:30 +0200, Ludwig Nussel a écrit :
Hi,
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
gnome-disks-utility (through udisks2) have SMART capabilities and have a monitor for SMART failure. I don't know if KDE has similar integration for this udisks2 capability. -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 10:54, Frederic Crozat wrote:
Le mercredi 08 octobre 2014 à 10:30 +0200, Ludwig Nussel a écrit :
Hi,
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
IF monitoring is enabled, the desktop user does get a notification on emergencies. I've seen it. Provoking a fake fault in order to see if the notification works I don't know how to do.
gnome-disks-utility (through udisks2) have SMART capabilities and have a monitor for SMART failure.
I don't know if KDE has similar integration for this udisks2 capability.
smartd is not on by default because supposedly dbus-daemon does it: /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11651): launched job udisks-helper-ata-smart-collect on /dev/sdd /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11653): launched job udisks-helper-ata-smart-collect on /dev/sde /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11654): launched job udisks-helper-ata-smart-collect on /dev/sdb /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:00:07 Telcontar dbus-daemon 1460 - - helper(pid 11655): launched job udisks-helper-ata-smart-collect on /dev/sdc /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata9/host8/target8:0:0/8:0:0:0/block/sdb /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - helper(pid 14055): launched job udisks-helper-ata-smart-collect on /dev/sdb /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata10/host9/target9:0:1/9:0:1:0/block/sde /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - helper(pid 14056): launched job udisks-helper-ata-smart-collect on /dev/sde /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata10/host9/target9:0:0/9:0:0:0/block/sdd /var/log/messages-20131104.xz:<3.6> 2013-11-04 01:30:07 Telcontar dbus-daemon 1460 - - helper(pid 14057): launched job udisks-helper-ata-smart-collect on /dev/sdd Although the messages are not supposed to be read by a human reading syslog. For that, the smard daemon is far better. And it emails you. Maybe dbus triggers the desktop notification :-? The messages stopped on 2014-08-09. I don't know why. zgrep -i smart /var/log/messages*xz | grep dbus-daemon | less -S Last entries: /var/log/messages-20140907.xz:<3.6> 2014-08-09 17:45:03 Telcontar dbus-daemon 1041 - - helper(pid 25517): launched job udisks-helper-ata-smart-collect on /dev/sdf /var/log/messages-20140907.xz:<3.6> 2014-08-09 17:45:03 Telcontar dbus-daemon 1041 - - **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/ata3/host2/target2:0:0/2:0:0:0/block/sdb /var/log/messages-20140907.xz:<3.6> 2014-08-09 17:45:03 Telcontar dbus-daemon 1041 - - helper(pid 25518): launched job udisks-helper-ata-smart-collect on /dev/sdb Now empty: Telcontar:~ # grep -i smart /var/log/messages | grep dbus-daemon Telcontar:~ # Telcontar:~ # locate udisks-helper-ata-smart-collect /other/test_a1/usr/lib/udisks/udisks-helper-ata-smart-collect /usr/lib/udisks/udisks-helper-ata-smart-collect Telcontar:~ # It's a binary, so I don't know what it is supposed to do really. HTH. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1E8UACgkQtTMYHG2NR9WjegCbBAmo7QBa4Uem2lvvuxPcZE5D Jt8An34NBM54TcvWfRYtjxwIM5S9ulCD =BQ0G -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-08 10:54, Frederic Crozat wrote:
Le mercredi 08 octobre 2014 à 10:30 +0200, Ludwig Nussel a écrit :
Hi,
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
IF monitoring is enabled, the desktop user does get a notification on emergencies. I've seen it. Provoking a fake fault in order to see if the notification works I don't know how to do.
gnome-disks-utility (through udisks2) have SMART capabilities and have a monitor for SMART failure.
I don't know if KDE has similar integration for this udisks2 capability.
smartd is not on by default because supposedly dbus-daemon does it:
No, that is not how it works. udisks2 has nothing to do with smartd, it has its own helper binary which reads SMART attributes, that is /usr/lib/udisks/udisks-helper-ata-smart-collect, and it doesn't log anything by default AFAIK. Rather it can signal warnings to desktop clients like gnome-disk-utility which in turn can create a notification for the user. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 12:59, Guido Berhoerster wrote:
* Carlos E. R. <> [2014-10-08 12:37]:
smartd is not on by default because supposedly dbus-daemon does it:
No, that is not how it works. udisks2 has nothing to do with smartd, it has its own helper binary which reads SMART attributes,
I know that.
that is /usr/lib/udisks/udisks-helper-ata-smart-collect, and it doesn't log anything by default AFAIK. Rather it can signal warnings to desktop clients like gnome-disk-utility which in turn can create a notification for the user.
It did generate a lot of entries in the log, till recently (I don't know why they stopped). And yes, someone told me that smartd was no longer needed, when I asked about it. That dbus/udisks did a better job. I did see the desktop notification once or twice. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1JeIACgkQtTMYHG2NR9VxqACeJTqHbZa5fyMZso0zLvZnIXfk sg0AnjqBugzPBprygem3nl29KiHwGRYH =mQXA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 08/10/14 a las #4, Carlos E. R. escribió: . That dbus/udisks did a better job. Dbus has nothing to do with this though, it is simply the mortician 's messenger in this case. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On October 8, 2014 6:36:55 AM EDT, "Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-08 10:54, Frederic Crozat wrote:
Le mercredi 08 octobre 2014 à 10:30 +0200, Ludwig Nussel a écrit :
Hi,
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
IF monitoring is enabled, the desktop user does get a notification on emergencies. I've seen it. Provoking a fake fault in order to see if the notification works I don't know how to do.
Create a trash file with a small amount of data in it. Figure out which physical sectors the data lives on. Flush the disk cache. (Drop cache) Use "hdparm --make-bad-sector" to temporarily trash one of those sectors. It will force an internal disk crc failure for the sector. (Hdparm does direct i/o and will bypass the kernel cache.) Then access the file (cp trash1 trash2). You should get an I/O error on the cp. When you're done "hdparm --repair-sector" should undo the damage. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 13:29, Greg Freemyer wrote:
On October 8, 2014 6:36:55 AM EDT, "Carlos E. R." <> wrote:
Provoking a fake fault in order to see if the notification works I don't know how to do.
Create a trash file with a small amount of data in it.
Figure out which physical sectors the data lives on.
Flush the disk cache. (Drop cache)
Use "hdparm --make-bad-sector" to temporarily trash one of those sectors. It will force an internal disk crc failure for the sector. (Hdparm does direct i/o and will bypass the kernel cache.)
Then access the file (cp trash1 trash2).
You should get an I/O error on the cp.
When you're done "hdparm --repair-sector" should undo the damage.
My hair is standing up in my back... yiks! :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1IZMACgkQtTMYHG2NR9UEJgCbBbVQ8yBDiZJh512/r1MfARvi kVIAn2334FXUcEdGMOU2Fs4PPzdN7HMt =Pztq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 8, 2014 at 7:35 AM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-08 13:29, Greg Freemyer wrote:
On October 8, 2014 6:36:55 AM EDT, "Carlos E. R." <> wrote:
Provoking a fake fault in order to see if the notification works I don't know how to do.
Create a trash file with a small amount of data in it.
Figure out which physical sectors the data lives on.
Flush the disk cache. (Drop cache)
Use "hdparm --make-bad-sector" to temporarily trash one of those sectors. It will force an internal disk crc failure for the sector. (Hdparm does direct i/o and will bypass the kernel cache.)
Then access the file (cp trash1 trash2).
You should get an I/O error on the cp.
When you're done "hdparm --repair-sector" should undo the damage.
My hair is standing up in my back... yiks!
:-)
I left out a key step I use: Find a SATA HDD with no content on it you care about and connect it to your system via sata and put a nice new filesystem on it. (I don't know if the above works for USB3 connected drives. I have never tried that.) You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 15:21, Greg Freemyer wrote:
On Wed, Oct 8, 2014 at 7:35 AM, Carlos E. R. <> wrote:
My hair is standing up in my back... yiks!
:-)
I left out a key step I use: Find a SATA HDD with no content on it you care about and connect it to your system via sata and put a nice new filesystem on it.
Ah, yes.
(I don't know if the above works for USB3 connected drives. I have never tried that.)
Maybe. Depends on the particular chipset of the hd box.
You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.
Right. Also, use ext3, not xfs: it is difficult to find the lba; far from trivial. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1RGsACgkQtTMYHG2NR9UNsgCcDCfD0+ckIpE0CIcfkjowwzzS +hYAnjZNe29FT7HF5m06in6jI8ynj5id =eYnV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Oct 8, 2014 at 10:04 AM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-10-08 15:21, Greg Freemyer wrote:
On Wed, Oct 8, 2014 at 7:35 AM, Carlos E. R. <> wrote:
My hair is standing up in my back... yiks!
:-)
I left out a key step I use: Find a SATA HDD with no content on it you care about and connect it to your system via sata and put a nice new filesystem on it.
Ah, yes.
(I don't know if the above works for USB3 connected drives. I have never tried that.)
Maybe. Depends on the particular chipset of the hd box.
You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.
Right.
Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.
My testing has actually been with raw unformated disks. Fill with random data: dd if=/dev/urandom of=/dev/sdx bs=4K use hdparm to corrupt a sector (or more) Use various raw sector level read tools to attempt to read the sector. Verify dd terminates when it hits the bad sector. What about "dd conv=noerror". Compare that to "dd conv=noerror,sync". What about shred /dev/sdx. Does it terminate on the bad sector? etc, etc, etc. I have run large numbers of similar tests over the last 10 years. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 16:10, Greg Freemyer wrote:
On Wed, Oct 8, 2014 at 10:04 AM, Carlos E. R. <> wrote:
Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.
My testing has actually been with raw unformated disks.
Fill with random data:
dd if=/dev/urandom of=/dev/sdx bs=4K
No need for data to be random for this particular test :-)
use hdparm to corrupt a sector (or more)
Use various raw sector level read tools to attempt to read the sector.
Verify dd terminates when it hits the bad sector. What about "dd conv=noerror". Compare that to "dd conv=noerror,sync".
What about shred /dev/sdx. Does it terminate on the bad sector?
etc, etc, etc.
I see. Yes, that's easier. Question: would not the write attempt to a failed sector automatically remap it, to one of those sectors reserved by the manufacturer for that purpose? In that case, I'm not sure it can be undone.
I have run large numbers of similar tests over the last 10 years.
Not many people have to :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1S5MACgkQtTMYHG2NR9VFgQCbBuJy9yjOjkCZ5LmgUxwjh1fi dPUAn1HV/59DCCJkJfEdF8s4LOjY3xyU =l/Jz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-10-08 16:04, Carlos E. R. wrote:
You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.
Right.
Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.
How so? The inode number multiplied by the inode size generally yields the LBA where the inode lives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 16:47, Jan Engelhardt wrote:
On Wednesday 2014-10-08 16:04, Carlos E. R. wrote:
You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.
Right.
Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.
How so? The inode number multiplied by the inode size generally yields the LBA where the inode lives.
My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1eCMACgkQtTMYHG2NR9XSFgCfZBW/8kH746PYP9102s/Ji4qi m7YAni7TSSOH3wadTSHtNFRUnILr7UHM =OiYS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-10-08 19:45, Carlos E. R. wrote:
You may also need to experiment with the 4K physical sectors vs. 512 byte logical sectors. All my testing has been with older 512 byte physical sector drives.
Right.
Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.
How so? The inode number multiplied by the inode size generally yields the LBA where the inode lives.
My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows.
And this is supposed to be easier on ext3? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.10.2014 um 20:19 schrieb Jan Engelhardt:
On Wednesday 2014-10-08 19:45, Carlos E. R. wrote:
My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows.
And this is supposed to be easier on ext3?
Yes, see http://smartmontools.sourceforge.net/badblockhowto.html (I don't know if it is hard on xfs, but it is easy on ext{23} -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2014-10-08 22:08, Stefan Seyfried wrote:
Am 08.10.2014 um 20:19 schrieb Jan Engelhardt:
On Wednesday 2014-10-08 19:45, Carlos E. R. wrote:
My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows.
And this is supposed to be easier on ext3?
Yes, see http://smartmontools.sourceforge.net/badblockhowto.html (I don't know if it is hard on xfs, but it is easy on ext{23}
For XFS, there is xfs_ncheck, which is a bit more direct than ext's debugfs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-08 20:19, Jan Engelhardt wrote:
On Wednesday 2014-10-08 19:45, Carlos E. R. wrote:
Also, use ext3, not xfs: it is difficult to find the lba; far from trivial.
How so? The inode number multiplied by the inode size generally yields the LBA where the inode lives.
My memory is fuzzy on this, but I think there is a thread on the xfs mail list asking about how to map sectors to files, nobody knows.
And this is supposed to be easier on ext3?
Well, it is at least documented, by the smartd people, in this precise scenario :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1v4MACgkQtTMYHG2NR9WqlACdEfTmelZHkWqjfsNJck4ipgxE dbcAn1AQRlbXGLTZc0zord6mvU27BzQJ =aWYQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-10-09 00:49, Carlos E. R. wrote:
Well, it is at least documented, by the smartd people, in this precise scenario :-)
Oh, sorry, confusion: The hard part is locating which file is on a known (lba) sector. It is much easier to locate on which sector lies a known file - obviously, as the kernel needs that knowledge and fast, in order to read any file. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQ1xxEACgkQtTMYHG2NR9WqNQCdF+siy/HSGUS7O2v40R78i5SI KosAnj0Wi/lCj4bMU6ttYw63IYjE9a4N =RrNO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 08/10/14 a las #4, Ludwig Nussel escribió:
Hi,
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
cu Ludwig
Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, October 08, 2014 02:51:30 PM Cristian Rodríguez wrote:
El 08/10/14 a las #4, Ludwig Nussel escribió:
Hi,
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
cu Ludwig
Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not.
What happens if nobody is logged in while the error occurs? Does udisk write a message to the syslog/journal? Should udisks or some watcher send an email to root@localhost or some other email address? Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 08/10/14 a las #4, Stefan Brüns escribió:
Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not.
What happens if nobody is logged in while the error occurs?
We are talking here about a desktop usecase, in which the user at some point will get to see the messages. What happens..? well if no one is subscribed to org.freedesktop.UDisks2.Drive.Ata checking for changes in SmartFailing property then there will be no notification. Does udisk write a message to the syslog/journal? Should udisks or some watcher send an email to root@localhost or some other email address? If you need that functionality try smartd..which is suitable for unattended systems. or make something else subscribe to the udisks dbus interface.. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez schrieb:
El 08/10/14 a las #4, Ludwig Nussel escribió:
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not.
I wasn't aware of udisks taking care. If that is the case smartd doesn't make sense on default desktop installs of course. It would still be interesting to know which desktops support smart via udisks. Too bad qemu doesn't seem to have support for SMART so we can't use openqa to check. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Ludwig Nussel
Cristian Rodríguez schrieb:
El 08/10/14 a las #4, Ludwig Nussel escribió:
After struggling with my harddisk I noticed that we don't have smartd enabled by default. Shouldn't we change that to get hard disk monitoring by default on every installation? But then IIUC smartd only logs to syslog which a desktop user will never see. Are there any ways to notify deskop users in case of imminent trouble?
Hrmmm.. I thought all major desktop environments reported smart failure if udisks tells so..I do not think we should enable smartd by default but make the notification work if it does not.
I wasn't aware of udisks taking care. If that is the case smartd doesn't make sense on default desktop installs of course. It would still be
udisks2 can just notify listeners over DBus. OTOH smartd has the ability to directly send mail, emit a wall(1) notification or to schedule a shutdown of the machine. I think just relying on desktop notifications is inadequate for this, desktops like GNOME make them easy to overlook, if you are not logged in, are using a window manager without a notification daemon, are logged in on the console, or are just logged in remotely you are likely to completely miss it. We need a notification mechanism that is both immediate and persistent, FDO desktop notifications totally fail at that.
interesting to know which desktops support smart via udisks.
codesearch.debian.net suggests that gnome-disk-utility is the only consumer of that API.
Too bad qemu doesn't seem to have support for SMART so we can't use openqa to check.
-- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Carlos E. R.
-
Carlos E. R.
-
Claudio Freire
-
Cristian Rodríguez
-
Frederic Crozat
-
Greg Freemyer
-
Guido Berhoerster
-
Jan Engelhardt
-
Ludwig Nussel
-
Stefan Brüns
-
Stefan Seyfried
-
Vahis