2:59 a.m.
I have an external 1 TB harddisk e-sata attached used for backups. The problem
is that I have few times lost connection to it. I have taken up the habit of
suspending (to RAM) when I leave the machine for a while and the problem seems
to happen when I reactivate the system though not every time. After a power
cycle the disk attaches correctly again. There is no trace of the problem in the
various logs so I am tempted to believe that it is caused by the suspend process
rather than a disk failure but since it is my backup device I would like to be
sure.
System: Fedora 16 with xfce 4.10
Kernel: 3.4.6-1.fc16.x86_64
Question: How can I run diagnose on the disk to see if it is about to fail
permanently?
--
Erik.
5:35 a.m.
On 07/30/2012 06:29 PM, Bryn M. Reeves wrote:
On Mon, 2012-07-30 at 18:20 +0800, Ed Greshko wrote:
> On 07/30/2012 06:16 PM, Bryn M. Reeves wrote:
>> In this case a suggestion that for whatever reason the kernel hasn't
>> properly dealt with the removal of the device that had been assigned to
>> sdd (it presumably existed at some point for the sysfs path to have been
>> created).
> Fresh install, 2 days ago.... Never had a drive there... And Never had a drive in
sdc either...
Do you have a card reader device?
Yes.... And that is sde.
>> If you're not getting entries in the logs when the problem happens you
>> can either look at other ways to get the logs out (e.g. serial console)
>> or you can try suspending and resuming from the console to see if
>> anything is printed (I have no idea if you are or not - you haven't
>> actually described the problem you are seeing so I'm just assuming it's
>> the "same" as Erik described since you are replying to his thread).
> I don't have *any* problems on my system.... I never said I did....check the
archive.
Not clear why you're replying to the thread then.
????? What? Only the OP with the problem is allowed? You mean I can't ask any
questions or give my input?
> I am simply dubious that this "state" has any valid meaning.
Supporting Linux storage configurations is my day job and I'd tend to
disagree. I guess the SCSI maintainers share that view since they've
chosen to maintain the file (and the internal state it maps to) for some
time.
Not knowing how debug from or interpret a particular piece of
information does not render that information useless.
Well... Since it is your day job. And I am sure you are willing to impart your wisdom
on folks....
If a drive is not plugged into a port, then what does "running" mean?
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled
5:01 a.m.
On Mon, 2012-07-30 at 06:48 -0300, Fernando Cassia wrote:
On Mon, Jul 30, 2012 at 6:32 AM, Bryn M. Reeves
<bmr(a)redhat.com> wrote:
> Do you see that happen a lot?
Do you mean the error, or the sharing of scripts?
The error: it's an abnormal condition so if you are seeing that,
especially if it is happening frequently, there is a problem.
When a device is removed the kernel issues remove uevents that should be
picked up by udev and cause the device nodes to be removed.
Bryn.
8:16 a.m.
On Mon, Jul 30, 2012 at 11:01:53AM +0100, Bryn M. Reeves wrote:
On Mon, 2012-07-30 at 06:48 -0300, Fernando Cassia wrote:
> On Mon, Jul 30, 2012 at 6:32 AM, Bryn M. Reeves <bmr(a)redhat.com> wrote:
> > Do you see that happen a lot?
>
> Do you mean the error, or the sharing of scripts?
The error: it's an abnormal condition so if you are seeing that,
especially if it is happening frequently, there is a problem.
When a device is removed the kernel issues remove uevents that should be
picked up by udev and cause the device nodes to be removed.
Bryn.
Well, FWIW, and at the risk of showing off my rather meager talents at bash
scripting (lol), my script simply checks that the drives aren't busy, and
then unmounts them before suspending. I still have to manually remount them
after I resume.
#! /bin/bash
umount /mnt/Ptec
if [ -e "/mnt/Ptec/Gentoo" ]; then
echo "Device Ptec Busy"
exit
else
umount /mnt/USB
fi
if [ -e "/mnt/USB/icons" ]; then
echo "Device USB Busy"
exit
else
/usr/sbin/hibernate-ram
fi
Terry
8:07 a.m.
On 30/07/12 12:11, Bryn M. Reeves wrote:
On Mon, 2012-07-30 at 12:09 +0200, Erik P. Olsen wrote:
> On 30/07/12 11:51, Bryn M. Reeves wrote:
>> On Mon, 2012-07-30 at 11:42 +0200, Erik P. Olsen wrote:
>>> On 30/07/12 10:44, Bryn M. Reeves wrote:
>>>> What state is the device in following a resume?
>>>> (/sys/block/sd*/device/state).
>>>
>>> What is that? I don't see anything near this path on my system. You
probably
>>> mean a faulty resume, in that case I'll have to wait til it happens
again.
>>
>> No, I meant what state the device is in following a resume.. It should
>> be "running" prior to the suspend (and at all times during normal
>> operation).
>>
>> The above path is a sysfs attribute that indicates the state of the
>> block device.
>>
>> E.g. for sda on my system:
>>
>> $ cat /sys/block/sda/device/state
>> running
>
> It says running both before and after suspend/resume.
When the problem occurs? You'll also need to adjust the device for the
one that's showing the problem. I used sda as an example as I'm
currently on a single disk machine.
No the problem didn't occur this time. It has happened twice the past ten days
and I was aware of the device address. Mine is sdc.
--
Erik
8:05 a.m.
On Mon, 2012-07-30 at 05:55 -0700, ny6p01(a)gmail.com wrote:
On Mon, Jul 30, 2012 at 09:44:24AM +0100, Bryn M. Reeves wrote:
> On Sun, 2012-07-29 at 20:13 -0700, ny6p01(a)gmail.com wrote:
> > That's not a disk problem. That's the disk failing to remount itself
> > properly after the suspend. This is very common. In fact, I wrote a script
> > (in Gentoo) to unmount external drives before a suspend operation, so that
> > the numbering of disks in /dev don't become littered with 'zombie'
drives.
> >
> > I'm sure there's a super-slick way of getting drives to remount
themselves
> > after a suspend, but mounting drives is relatively easy to do either with
> > gui or cli tools, so I don't tear my hair over it.
>
> An eSATA device should be able to suspend and resume properly (just like
> the other ATA devices in your system).
>
> Debugging it may be difficult unless you can get console logs showing
> what's happening during the suspend/resume cycle (serial console or
> possibly netconsole).
>
> What state is the device in following a resume?
> (/sys/block/sd*/device/state).
>
Never knew about that file. Thanks!
It only shows the SCSI state of the device but it can be a useful check
when trying to narrow down the problem. If the SCSI layer was aware of
problems it will often have set the state to 'offline'. If the device is
out to lunch but the file still shows 'running' it suggests that there
is a problem lower down and that the upper layers have not been informed
of a problem.
Bryn.
7:59 a.m.
On Mon, Jul 30, 2012 at 06:20:53PM +0800, Ed Greshko wrote:
On 07/30/2012 06:16 PM, Bryn M. Reeves wrote:
> In this case a suggestion that for whatever reason the kernel hasn't
> properly dealt with the removal of the device that had been assigned to
> sdd (it presumably existed at some point for the sysfs path to have been
> created).
Fresh install, 2 days ago.... Never had a drive there... And Never had a drive in sdc
either...
Well, when you do, it'll be ready. And running. :0
[egreshko@meimei block]$ cat /sys/block/sdc/device/state
running
>
> If you're not getting entries in the logs when the problem happens you
> can either look at other ways to get the logs out (e.g. serial console)
> or you can try suspending and resuming from the console to see if
> anything is printed (I have no idea if you are or not - you haven't
> actually described the problem you are seeing so I'm just assuming it's
> the "same" as Erik described since you are replying to his thread).
I don't have *any* problems on my system.... I never said I did....check the
archive.
I am simply dubious that this "state" has any valid meaning.
Terry
7:55 a.m.
On Mon, Jul 30, 2012 at 09:44:24AM +0100, Bryn M. Reeves wrote:
On Sun, 2012-07-29 at 20:13 -0700, ny6p01(a)gmail.com wrote:
> That's not a disk problem. That's the disk failing to remount itself
> properly after the suspend. This is very common. In fact, I wrote a script
> (in Gentoo) to unmount external drives before a suspend operation, so that
> the numbering of disks in /dev don't become littered with 'zombie'
drives.
>
> I'm sure there's a super-slick way of getting drives to remount themselves
> after a suspend, but mounting drives is relatively easy to do either with
> gui or cli tools, so I don't tear my hair over it.
An eSATA device should be able to suspend and resume properly (just like
the other ATA devices in your system).
Debugging it may be difficult unless you can get console logs showing
what's happening during the suspend/resume cycle (serial console or
possibly netconsole).
What state is the device in following a resume?
(/sys/block/sd*/device/state).
Never knew about that file. Thanks!
Terry
5:56 a.m.
On 07/30/2012 06:51 PM, Bryn M. Reeves wrote:
Not at all but posts should be relevant to the thread and explain
anything that other readers might need to know (like the fact that you
don't have any problems, are running commands on a different type of
device that's also removable etc.).
Whatever..... I looked back on the thread and didn't see you jumping on others for
putting in their $.02 and not pointing out that that don't have problems......
I try to remember your sage advice.
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled
5:53 a.m.
On 07/30/2012 06:35 PM, Ed Greshko wrote:
Well... Since it is your day job. And I am sure you are willing
to impart your wisdom on folks....
If a drive is not plugged into a port, then what does "running" mean?
Hummm..... Now I find this "strange".
I had done a "Net" install on this system and it fully updated at install time.
As such I had never rebooted. I decided I wanted to plug in a drive to do some
"testing".
On reboot, the SD card reader became sdc and the sdd device is gone.
So, I hope you can see your way clear to understand the confusion.
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled
5:51 a.m.
On Mon, 2012-07-30 at 18:35 +0800, Ed Greshko wrote:
On 07/30/2012 06:29 PM, Bryn M. Reeves wrote:
> Do you have a card reader device?
Yes.... And that is sde.
I would guess it's a multi-card reader device and those additional SCSI
device nodes correspond to empty slots within the reader (and you'll
probably find that the removable attribute is set on them).
????? What? Only the OP with the problem is allowed? You mean I
can't ask any questions or give my input?
Not at all but posts should be relevant to the thread and explain
anything that other readers might need to know (like the fact that you
don't have any problems, are running commands on a different type of
device that's also removable etc.).
Posting random output from your machine as though it proves something is
not helpful to anyone and just serves to confuse people.
Install sg3_utils and run "sg_map -i" if you really want to know (with
root privileges if you want the inquiries to succeed).
Well... Since it is your day job. And I am sure you are willing
to impart your wisdom on folks....
Fedora lists are something I do on my own time for fun and because I am
a user of the distribution. I don't get paid for that.
If a drive is not plugged into a port, then what does
"running" mean?
In your case I would imagine that it's a removable SCSI device that has
no media present but you're asking us to investigate through a letterbox
- if you're interested in understanding something you need to post
enough information about it that readers can make an informed comment.
Bryn.
5:29 a.m.
On Mon, 2012-07-30 at 18:20 +0800, Ed Greshko wrote:
On 07/30/2012 06:16 PM, Bryn M. Reeves wrote:
> In this case a suggestion that for whatever reason the kernel hasn't
> properly dealt with the removal of the device that had been assigned to
> sdd (it presumably existed at some point for the sysfs path to have been
> created).
Fresh install, 2 days ago.... Never had a drive there... And Never had a drive in sdc
either...
Do you have a card reader device?
> If you're not getting entries in the logs when the problem
happens you
> can either look at other ways to get the logs out (e.g. serial console)
> or you can try suspending and resuming from the console to see if
> anything is printed (I have no idea if you are or not - you haven't
> actually described the problem you are seeing so I'm just assuming it's
> the "same" as Erik described since you are replying to his thread).
I don't have *any* problems on my system.... I never said I did....check the
archive.
Not clear why you're replying to the thread then.
I am simply dubious that this "state" has any valid
meaning.
Supporting Linux storage configurations is my day job and I'd tend to
disagree. I guess the SCSI maintainers share that view since they've
chosen to maintain the file (and the internal state it maps to) for some
time.
Not knowing how debug from or interpret a particular piece of
information does not render that information useless.
Bryn.
5:20 a.m.
On 07/30/2012 06:16 PM, Bryn M. Reeves wrote:
In this case a suggestion that for whatever reason the kernel
hasn't
properly dealt with the removal of the device that had been assigned to
sdd (it presumably existed at some point for the sysfs path to have been
created).
Fresh install, 2 days ago.... Never had a drive there... And Never had a drive in sdc
either...
[egreshko@meimei block]$ cat /sys/block/sdc/device/state
running
If you're not getting entries in the logs when the problem happens you
can either look at other ways to get the logs out (e.g. serial console)
or you can try suspending and resuming from the console to see if
anything is printed (I have no idea if you are or not - you haven't
actually described the problem you are seeing so I'm just assuming it's
the "same" as Erik described since you are replying to his thread).
I don't have *any* problems on my system.... I never said I did....check the
archive.
I am simply dubious that this "state" has any valid meaning.
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled
5:16 a.m.
On Mon, 2012-07-30 at 18:04 +0800, Ed Greshko wrote:
On 07/30/2012 05:59 PM, Bryn M. Reeves wrote:
> On Mon, 2012-07-30 at 17:47 +0800, Ed Greshko wrote:
>> On 07/30/2012 04:44 PM, Bryn M. Reeves wrote:
>>> What state is the device in following a resume?
>>> (/sys/block/sd*/device/state).
>> I am not so sure that is a "good" indication of anything. I have 2
drives on my system /dev/sda and /dev/sdb.
> It's a fine indication of the state the kernel thinks the device is in
> (that's what it's there for). If that file indicates the device is
> running but in fact you can't issue I/O to it you'd suspect a problem in
> the driver. If it's blocked or offlined you can look into what caused
> that to happen.
>
>> [egreshko@meimei block]$ cat /sys/block/sdd/device/state
>> running
> Are they working? What are you trying to prove? For an active, working
> device this is the normal state.
>
>
There is no disk plugged into the SATA port. As I said.... I only have 2 sda and sdb.
There is no sdD.
So, what is "running"?
In this case a suggestion that for whatever reason the kernel hasn't
properly dealt with the removal of the device that had been assigned to
sdd (it presumably existed at some point for the sysfs path to have been
created).
If you're not getting entries in the logs when the problem happens you
can either look at other ways to get the logs out (e.g. serial console)
or you can try suspending and resuming from the console to see if
anything is printed (I have no idea if you are or not - you haven't
actually described the problem you are seeing so I'm just assuming it's
the "same" as Erik described since you are replying to his thread).
Bryn.
5:11 a.m.
On Mon, 2012-07-30 at 12:09 +0200, Erik P. Olsen wrote:
On 30/07/12 11:51, Bryn M. Reeves wrote:
> On Mon, 2012-07-30 at 11:42 +0200, Erik P. Olsen wrote:
>> On 30/07/12 10:44, Bryn M. Reeves wrote:
>>> What state is the device in following a resume?
>>> (/sys/block/sd*/device/state).
>>
>> What is that? I don't see anything near this path on my system. You
probably
>> mean a faulty resume, in that case I'll have to wait til it happens again.
>
> No, I meant what state the device is in following a resume.. It should
> be "running" prior to the suspend (and at all times during normal
> operation).
>
> The above path is a sysfs attribute that indicates the state of the
> block device.
>
> E.g. for sda on my system:
>
> $ cat /sys/block/sda/device/state
> running
It says running both before and after suspend/resume.
When the problem occurs? You'll also need to adjust the device for the
one that's showing the problem. I used sda as an example as I'm
currently on a single disk machine.
Bryn.
5:09 a.m.
On 30/07/12 11:51, Bryn M. Reeves wrote:
On Mon, 2012-07-30 at 11:42 +0200, Erik P. Olsen wrote:
> On 30/07/12 10:44, Bryn M. Reeves wrote:
>> What state is the device in following a resume?
>> (/sys/block/sd*/device/state).
>
> What is that? I don't see anything near this path on my system. You probably
> mean a faulty resume, in that case I'll have to wait til it happens again.
No, I meant what state the device is in following a resume.. It should
be "running" prior to the suspend (and at all times during normal
operation).
The above path is a sysfs attribute that indicates the state of the
block device.
E.g. for sda on my system:
$ cat /sys/block/sda/device/state
running
It says running both before and after suspend/resume.
--
Erik
5:04 a.m.
On 07/30/2012 05:59 PM, Bryn M. Reeves wrote:
On Mon, 2012-07-30 at 17:47 +0800, Ed Greshko wrote:
> On 07/30/2012 04:44 PM, Bryn M. Reeves wrote:
>> What state is the device in following a resume?
>> (/sys/block/sd*/device/state).
> I am not so sure that is a "good" indication of anything. I have 2 drives
on my system /dev/sda and /dev/sdb.
It's a fine indication of the state the kernel thinks the device is in
(that's what it's there for). If that file indicates the device is
running but in fact you can't issue I/O to it you'd suspect a problem in
the driver. If it's blocked or offlined you can look into what caused
that to happen.
> [egreshko@meimei block]$ cat /sys/block/sdd/device/state
> running
Are they working? What are you trying to prove? For an active, working
device this is the normal state.
There is no disk plugged into the SATA port. As I said.... I only have 2 sda and sdb.
There is no sdD.
So, what is "running"?
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled
4:59 a.m.
On Mon, 2012-07-30 at 17:47 +0800, Ed Greshko wrote:
On 07/30/2012 04:44 PM, Bryn M. Reeves wrote:
> What state is the device in following a resume?
> (/sys/block/sd*/device/state).
I am not so sure that is a "good" indication of anything. I have 2 drives on
my system /dev/sda and /dev/sdb.
It's a fine indication of the state the kernel thinks the device is in
(that's what it's there for). If that file indicates the device is
running but in fact you can't issue I/O to it you'd suspect a problem in
the driver. If it's blocked or offlined you can look into what caused
that to happen.
[egreshko@meimei block]$ cat /sys/block/sdd/device/state
running
Are they working? What are you trying to prove? For an active, working
device this is the normal state.
4:47 a.m.
On 07/30/2012 04:44 PM, Bryn M. Reeves wrote:
What state is the device in following a resume?
(/sys/block/sd*/device/state).
I am not so sure that is a "good" indication of anything. I have 2 drives on my
system /dev/sda and /dev/sdb.
[egreshko@meimei block]$ cat /sys/block/sdd/device/state
running
I don't think so.....
--
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning. -- Rick Cook, The Wizardry Compiled
4:51 a.m.
On Mon, 2012-07-30 at 11:42 +0200, Erik P. Olsen wrote:
On 30/07/12 10:44, Bryn M. Reeves wrote:
> What state is the device in following a resume?
> (/sys/block/sd*/device/state).
What is that? I don't see anything near this path on my system. You probably
mean a faulty resume, in that case I'll have to wait til it happens again.
No, I meant what state the device is in following a resume.. It should
be "running" prior to the suspend (and at all times during normal
operation).
The above path is a sysfs attribute that indicates the state of the
block device.
E.g. for sda on my system:
$ cat /sys/block/sda/device/state
running
Bryn.
4:42 a.m.
On 30/07/12 10:44, Bryn M. Reeves wrote:
On Sun, 2012-07-29 at 20:13 -0700, ny6p01(a)gmail.com wrote:
> That's not a disk problem. That's the disk failing to remount itself
> properly after the suspend. This is very common. In fact, I wrote a script
> (in Gentoo) to unmount external drives before a suspend operation, so that
> the numbering of disks in /dev don't become littered with 'zombie'
drives.
>
> I'm sure there's a super-slick way of getting drives to remount themselves
> after a suspend, but mounting drives is relatively easy to do either with
> gui or cli tools, so I don't tear my hair over it.
An eSATA device should be able to suspend and resume properly (just like
the other ATA devices in your system).
It does so most of the time.
Debugging it may be difficult unless you can get console logs showing
what's happening during the suspend/resume cycle (serial console or
possibly netconsole).
What state is the device in following a resume?
(/sys/block/sd*/device/state).
What is that? I don't see anything near this path on my system. You probably
mean a faulty resume, in that case I'll have to wait til it happens again.
--
Erik
4:32 a.m.
On Mon, 2012-07-30 at 06:29 -0300, Fernando Cassia wrote:
On Mon, Jul 30, 2012 at 12:13 AM, <ny6p01(a)gmail.com> wrote:
> This is very common. In fact, I wrote a script
> (in Gentoo) to unmount external drives before a suspend operation, so that
> the numbering of disks in /dev don't become littered with 'zombie'
drives.
It would be great if you could share it...
Do you see that happen a lot?
Bryn.
4:29 a.m.
On Mon, Jul 30, 2012 at 12:13 AM, <ny6p01(a)gmail.com> wrote:
This is very common. In fact, I wrote a script
(in Gentoo) to unmount external drives before a suspend operation, so that
the numbering of disks in /dev don't become littered with 'zombie' drives.
It would be great if you could share it...
FC
3:44 a.m.
On Sun, 2012-07-29 at 20:13 -0700, ny6p01(a)gmail.com wrote:
That's not a disk problem. That's the disk failing to remount
itself
properly after the suspend. This is very common. In fact, I wrote a script
(in Gentoo) to unmount external drives before a suspend operation, so that
the numbering of disks in /dev don't become littered with 'zombie' drives.
I'm sure there's a super-slick way of getting drives to remount themselves
after a suspend, but mounting drives is relatively easy to do either with
gui or cli tools, so I don't tear my hair over it.
An eSATA device should be able to suspend and resume properly (just like
the other ATA devices in your system).
Debugging it may be difficult unless you can get console logs showing
what's happening during the suspend/resume cycle (serial console or
possibly netconsole).
What state is the device in following a resume?
(/sys/block/sd*/device/state).
Regards,
Bryn.
10:13 p.m.
On Sun, Jul 29, 2012 at 09:59:56AM +0200, Erik P. Olsen wrote:
I have an external 1 TB harddisk e-sata attached used for backups.
The problem is that I have few times lost connection to it. I have
taken up the habit of suspending (to RAM) when I leave the machine
for a while and the problem seems to happen when I reactivate the
system though not every time. After a power cycle the disk attaches
correctly again. There is no trace of the problem in the various
logs so I am tempted to believe that it is caused by the suspend
process rather than a disk failure but since it is my backup device
I would like to be sure.
System: Fedora 16 with xfce 4.10
Kernel: 3.4.6-1.fc16.x86_64
Question: How can I run diagnose on the disk to see if it is about
to fail permanently?
That's not a disk problem. That's the disk failing to remount itself
properly after the suspend. This is very common. In fact, I wrote a script
(in Gentoo) to unmount external drives before a suspend operation, so that
the numbering of disks in /dev don't become littered with 'zombie' drives.
I'm sure there's a super-slick way of getting drives to remount themselves
after a suspend, but mounting drives is relatively easy to do either with
gui or cli tools, so I don't tear my hair over it.
Terry
4294
days inactive
4295
days old
25 comments
5 participants
participants (5)
-
Bryn M. Reeves -
Ed Greshko -
Erik P. Olsen -
Fernando Cassia -
Lee