Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #206454 > unrolled thread

iotop - or, checking what is accessing a drive

Back to article view | Back to linux.debian.user

Contents

  iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-22 16:30 +0100
    Re: iotop - or, checking what is accessing a drive Reco <recoverym4n@enotuniq.net> - 2019-03-22 17:00 +0100
      Reco - Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-22 18:30 +0100
        Re: Reco - Re: iotop - or, checking what is accessing a drive David <bouncingcats@gmail.com> - 2019-03-23 01:40 +0100
          Re: Reco - Re: iotop - or, checking what is accessing a drive Tixy <tixy@yxit.co.uk> - 2019-03-23 08:40 +0100
    Re: iotop - or, checking what is accessing a drive Michael Stone <mstone@debian.org> - 2019-03-22 17:30 +0100
      Michael - Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-22 18:30 +0100
        Re: Michael - Re: iotop - or, checking what is accessing a drive Curt <curty@free.fr> - 2019-03-22 18:50 +0100
          Curt --- Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-22 19:10 +0100
            Re: Curt --- Re: iotop - or, checking what is accessing a drive Michael Stone <mstone@debian.org> - 2019-03-22 21:10 +0100
              Re: Curt --- Re: iotop - or, checking what is accessing a drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-22 21:30 +0100
                Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-23 02:30 +0100
              Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-22 21:30 +0100
                Re: iotop - or, checking what is accessing a drive Cindy-Sue Causey <butterflybytes@gmail.com> - 2019-03-22 21:50 +0100
                  Re: iotop - or, checking what is accessing a drive Curt <curty@free.fr> - 2019-03-22 22:20 +0100
                Re: iotop - or, checking what is accessing a drive Cindy-Sue Causey <butterflybytes@gmail.com> - 2019-03-22 21:50 +0100
                Re: iotop - or, checking what is accessing a drive Michael Stone <mstone@debian.org> - 2019-03-23 00:40 +0100
                  Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-23 02:20 +0100
                    Re: iotop - or, checking what is accessing a drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-23 04:40 +0100
            Re: Curt --- Re: iotop - or, checking what is accessing a drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-22 21:10 +0100
              Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-22 21:20 +0100
                Re: iotop - or, checking what is accessing a drive David Wright <deblis@lionunicorn.co.uk> - 2019-03-23 05:00 +0100
              Re: Curt --- Re: iotop - or, checking what is accessing a drive Cindy-Sue Causey <butterflybytes@gmail.com> - 2019-03-22 21:30 +0100
                Re: iotop - or, checking what is accessing a drive deb <deb@rangingthoughts.org> - 2019-03-23 02:20 +0100

Page 1 of 2  [1] 2  Next page →

#206454 — iotop - or, checking what is accessing a drive

[Multipart message — attachments visible in raw view] — view raw

Hello folks:


Situation:

   Plenty of portable NTFS drives, occasionally hooked to debian.

   The drive's light stays on [indicating use] even when dismounted (but 
still connected via USB).


   I'd like to try and find out what's using the drive.

   I don't like the idea of just yanking the cable...

   I can not afford to trash data.

   I found iotop below (a top for processes creating I/O).



a.  Has anyone used iotop? thoughts?

(I did -- it's CLI-based. I was underwhelmed. Hard-ish to use; can't 
easily pinpoint processes accessing the drives)


b. Can anyone recommend a different tool?

Thanks!


My info was found here:


https://www.hecticgeek.com/2015/01/ext4-external-hard-disk-busy-at-idle-fix/


  "My Newly Formatted (‘Ext4’) External Hard Disk is Busy, Even at Idle
  [Fix]

January 8, 2015 
<https://www.hecticgeek.com/2015/01/ext4-external-hard-disk-busy-at-idle-fix/> 
by Gayan <https://www.hecticgeek.com/author/gayan/>

I recently purchased a Western Digital My Passport Ultra (1TB, USB 3.0) 
external hard disk as I was running out of space to save my 
files. Although I dual-boot a GNU/Linux 
<https://www.hecticgeek.com/gnu-linux/> distribution (which is the 
awesome Fedora 21 
<https://www.hecticgeek.com/2014/12/fedora-21-review/> nowadays) with 
Windows 8.1, and almost all of my friends rely on the Windows operating 
system, I took the decision to format it into ‘Ext4’ anyway, despite 
having the obvious drawback to which I am bound (that would be sharing 
data of course  ).

To be honest, I never had used a native GNU/Linux file system on a large 
USB hard disk before, thus, after creating an ‘Ext4’ file system on the 
1TB USB drive, I made an interesting (and irritating) observation. What 
happened was that, after formatting the drive into ‘Ext4’, whenever I 
mounted the USB disk, even when I was not using it, the LED starts to 
indicate (by blinking) a mild disk activity.

I ignored it the first time, but every time I mounted the drive, it 
happened again and again. And on all these instances the LED kept 
blinking non-stop for minutes and the only way stop it was to detach the 
USB disk from the computer. So in an attempt to isolate its cause, I 
used the ‘iotop 
<https://www.hecticgeek.com/2012/03/iotop-disk-io-monitor-ubuntu-linux/>‘ 
utility (it’s a tool that sorts & lists processes by their disk I/O 
consumption). And as soon as I opened it, ‘iotop’ listed a process 
called ‘ext4lazyinit’ that was consuming a mild I/O bandwidth (about 
11-13 Mb/s) out of my WD USB hard disk."

[toc] | [next] | [standalone]

#206457

	Hi.

On Fri, Mar 22, 2019 at 11:23:29AM -0400, deb wrote:
> a.  Has anyone used iotop? thoughts?

Implemented in Python, so it's a toy. Was *the* thing back in 2.6.x
kernel's days.


> b. Can anyone recommend a different tool?

"iostat -kx 1" to pinpoint a drive.
"pidstat -dl 1" to point at a process eating I/O.

Both come with "sysstat" package.

"perf top", but it *does* require skill, knowledge and determination.

Reco

[toc] | [prev] | [next] | [standalone]

#206465 — Reco - Re: iotop - or, checking what is accessing a drive

[Multipart message — attachments visible in raw view] — view raw

On 3/22/19 11:56 AM, Reco wrote:
> 	Hi.
>
> On Fri, Mar 22, 2019 at 11:23:29AM -0400, deb wrote:
>> a.  Has anyone used iotop? thoughts?
> Implemented in Python, so it's a toy. Was*the*  thing back in 2.6.x
> kernel's days.
>
>
>> b. Can anyone recommend a different tool?
> "iostat -kx 1" to pinpoint a drive.
> "pidstat -dl 1" to point at a process eating I/O.
>
> Both come with "sysstat" package.
>
> "perf top", but it*does*  require skill, knowledge and determination.
>
> Reco
>
>

There you go!

Good answer.

I saw the python in iotop as well and had doubts from there.


If it was an ext4 drive on Linux, I'd be thinking lazy ext4 init,


I'm looking at hdparm -C too.


Thank you Reco

[toc] | [prev] | [next] | [standalone]

#206499 — Re: Reco - Re: iotop - or, checking what is accessing a drive

Hi deb

I don't know why you have a habit of editing the message
subject to add people's names, but I ask you to stop doing it.

Please only edit the message subject when it no longer
represents the content of the message.

Please note:
1) Everybody else here does this. When participating in a
community, it is polite to respect and observe the community
behaviour.
2) You are messing up the archive indexes, for example
look here:
https://lists.debian.org/debian-user/2019/03/subject.html
This page and others becomes a mess because you keep
changing the subject.

[toc] | [prev] | [next] | [standalone]

#206512 — Re: Reco - Re: iotop - or, checking what is accessing a drive

On Sat, 2019-03-23 at 11:31 +1100, David wrote:
> Hi deb
> 
> I don't know why you have a habit of editing the message
> subject to add people's names, but I ask you to stop doing it.

I second that request for the same reasons David said, also seeing
someone else's name at the start of subject lines makes it look a lot
like spam.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#206459

On Fri, Mar 22, 2019 at 11:23:29AM -0400, deb wrote:
>a.  Has anyone used iotop? thoughts?
>
>(I did -- it's CLI-based. I was underwhelmed. Hard-ish to use; can't easily
>pinpoint processes accessing the drives)

Well, it's hard to say what would work better if you can't explain what 
the problem is with iotop. By default it sorts by io %, which isn't 
necessarily the best view. Left and right arrows highlight and sort by 
other columns, and it may be more useful to look at reads and writes 
individually.

Depending on what's on the disk, it might be more useful to just use 
lsof to see what files are open and try to understand what those might 
be doing. 

[toc] | [prev] | [next] | [standalone]

#206467 — Michael - Re: iotop - or, checking what is accessing a drive

On 3/22/19 12:24 PM, Michael Stone wrote:
> On Fri, Mar 22, 2019 at 11:23:29AM -0400, deb wrote:
>> a.  Has anyone used iotop? thoughts?
>>
>> (I did -- it's CLI-based. I was underwhelmed. Hard-ish to use; can't 
>> easily
>> pinpoint processes accessing the drives)
>
> Well, it's hard to say what would work better if you can't explain 
> what the problem is with iotop. By default it sorts by io %, which 
> isn't necessarily the best view. Left and right arrows highlight and 
> sort by other columns, and it may be more useful to look at reads and 
> writes individually.
>
> Depending on what's on the disk, it might be more useful to just use 
> lsof to see what files are open and try to understand what those might 
> be doing.
>

Thank you Michael.

I'll build up a list of these recommendations for here.


I'm looking at hdparm -C too.

No --help on that one.

man hdparm

-C  Check  the  current  IDE power mode status, which will always be
               one  of  unknown  (drive  does  not   support this   
command),
               active/idle  (normal  operation), standby (low power 
mode, drive
               has spun down), or sleeping (lowest power mode, drive  
is  com‐
               pletely  shut down).  The -S, -y, -Y, and -Z options can 
be used
               to manipulate the IDE power modes.

Thank you

[toc] | [prev] | [next] | [standalone]

#206470 — Re: Michael - Re: iotop - or, checking what is accessing a drive

On 2019-03-22, deb <deb@rangingthoughts.org> wrote:
>
>>
>> Depending on what's on the disk, it might be more useful to just use 
>> lsof to see what files are open and try to understand what those might 
>> be doing.
>>
>
> Thank you Michael.
>
> I'll build up a list of these recommendations for here.
>
>

I believe you said that the external USB drive's LED remains on, even
after unmounting, and that indicates to you that there's activity on the
drive. I've always labored under the idea that a *flashing* light
indicated activity and a steady one an idle state.

Now it occurs to me that these signal indications may depend on the make
and model of the drive itself.

What should be the behavior of the LED on your drive when the drive is
unmounted and/or inactive? 

(This is probably a waste of everybody's time.)

-- 
“Let us again pretend that life is a solid substance, shaped like a globe,
which we turn about in our fingers. Let us pretend that we can make out a plain
and logical story, so that when one matter is despatched--love for instance--
we go on, in an orderly manner, to the next.” - Virginia Woolf, The Waves

[toc] | [prev] | [next] | [standalone]

#206472 — Curt --- Re: iotop - or, checking what is accessing a drive

On 3/22/19 1:48 PM, Curt wrote:
> On 2019-03-22, deb <deb@rangingthoughts.org> wrote:
>>> Depending on what's on the disk, it might be more useful to just use
>>> lsof to see what files are open and try to understand what those might
>>> be doing.
>>>
>> Thank you Michael.
>>
>> I'll build up a list of these recommendations for here.
>>
>>
> I believe you said that the external USB drive's LED remains on, even
> after unmounting, and that indicates to you that there's activity on the
> drive. I've always labored under the idea that a *flashing* light
> indicated activity and a steady one an idle state.
>
> Now it occurs to me that these signal indications may depend on the make
> and model of the drive itself.
>
> What should be the behavior of the LED on your drive when the drive is
> unmounted and/or inactive?
>
> (This is probably a waste of everybody's time.)
>


 > (This is probably a waste of everybody's time.)

Not of mine.

Or a bunch of users.


YES -- this differs by manufacturer.


Just a reminder -- the bulk of mine are Seagate Backup Plus (1-5TB. USB 
3.0).
On Windows, when you dismount (Safely Remove) these
the light goes off.


It is On when connected and very dimmly flashed when being accessed.
So, it can flash a bit when indexes are up[dated,
or a file is flushed -- and go right back to steady on.


I only *feel* safe, pulling the cable when the light is OFF.


Again, I can NOT suffer a data-loss-because-of-Evil-Linux situation,
giving the Windows-folk ammo.



I wanted to switch to your name in the Subject Curt,
but Jim P. will yell at me. :-)


Screw it --- I switched it anyway.

[toc] | [prev] | [next] | [standalone]

#206481 — Re: Curt --- Re: iotop - or, checking what is accessing a drive

On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
>If you're really worried, first remount the partitions readonly, which
>will fail if they're in use. Then unmount them and disconnect.

Just unmount--that will fail if the partition is in use unless extra 
options are added.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#206486 — Re: Curt --- Re: iotop - or, checking what is accessing a drive

On Fri 22 Mar 2019 at 16:07:24 (-0400), Michael Stone wrote:
> On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
> > If you're really worried, first remount the partitions readonly, which
> > will fail if they're in use. Then unmount them and disconnect.
> 
> Just unmount--that will fail if the partition is in use unless extra
> options are added.

Sorry, it hadn't occurred to me that the OP wasn't just doing that
(because they had said they used "Safely Remove" in Windows).
Nor had it occurred to me that one might need a bettery of tools
like iotop, hdparm, iostat, pidstat, perf top, and the rest,
rather than just unmounting. I thought they wanted a belt and braces
method, a bit of redundancy.

So it's just the usual Pose Problem A, Solve Problem B.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206506

On 3/22/19 4:25 PM, David Wright wrote:
> On Fri 22 Mar 2019 at 16:07:24 (-0400), Michael Stone wrote:
>> On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
>>> If you're really worried, first remount the partitions readonly, which
>>> will fail if they're in use. Then unmount them and disconnect.
>> Just unmount--that will fail if the partition is in use unless extra
>> options are added.
> Sorry, it hadn't occurred to me that the OP wasn't just doing that
> (because they had said they used "Safely Remove" in Windows).
> Nor had it occurred to me that one might need a bettery of tools
> like iotop, hdparm, iostat, pidstat, perf top, and the rest,
> rather than just unmounting. I thought they wanted a belt and braces
> method, a bit of redundancy.
>
> So it's just the usual Pose Problem A, Solve Problem B.
>
> Cheers,
> David.

To summarize, I had been unmounting (multiple times, NO errors)
as well as eject -ing.
Drives still have hard light on.
This is different behavior than on Windows, where the light goes off 
signaling it's ready to to be removed.
Same drives in both cases.


I am quite happy to have the battery of recommended tools to see what is 
accessing the drives BEFORE ever unmounting at all.

At least Linux has these tools.

It is often a sysinternals-level jaunt on Windows to figure out what's 
tying up a drive. Their default error messages are a joke.

[toc] | [prev] | [next] | [standalone]

#206487

On 3/22/19 4:07 PM, Michael Stone wrote:
> On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
>> If you're really worried, first remount the partitions readonly, which
>> will fail if they're in use. Then unmount them and disconnect.
>
> Just unmount--that will fail if the partition is in use unless extra 
> options are added.
>
> Mike Stone
>
>

Actually no.

That's where I started at.


A given drive should behave the same on Windows & Linux as far as lights 
on/off/dimming.

But as I noted earlier, on Windows, the light is OFF, signaling no drive 
activity upon being removed.

On debian 9.8, it stays on, after repeated dismounts.


Hence my request for tools to (easily) see what's going on.

*Something* is hitting the drive.

Thanks

[toc] | [prev] | [next] | [standalone]

#206490

On 3/22/19, deb <deb@rangingthoughts.org> wrote:
>
> A given drive should behave the same on Windows & Linux as far as lights
> on/off/dimming.
>
> But as I noted earlier, on Windows, the light is OFF, signaling no drive
> activity upon being removed.
>
> On debian 9.8, it stays on, after repeated dismounts.
>
>
> Hence my request for tools to (easily) see what's going on.
>
> *Something* is hitting the drive.


*Your* words reminded that I suspected a website of repeatedly poking
my exterior hard drive when it had no business doing so. I was just
about to poke Brian Krebs (KrebsOnSecuirty) and ask him to test if
that's what was going on, but that behavior ceased when the
potentially offending website was redesigned...

For my instances, the drive was mounted but very idle... except for
those times the light would start beaconing when I landed on that one
consumer website.....

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#206492

On 2019-03-22, Cindy-Sue Causey <butterflybytes@gmail.com> wrote:
>
> For my instances, the drive was mounted but very idle... except for
> those times the light would start beaconing when I landed on that one
> consumer website.....

AFAIK unmounted hard drives are inaccessible to the operating system by
definition.

Wrong tree, meet barking dog?

> Cindy :)

[toc] | [prev] | [next] | [standalone]

#206491

On 3/22/19, deb <deb@rangingthoughts.org> wrote:
>
> A given drive should behave the same on Windows & Linux as far as lights
> on/off/dimming.
>
> But as I noted earlier, on Windows, the light is OFF, signaling no drive
> activity upon being removed.
>
> On debian 9.8, it stays on, after repeated dismounts.
>
>
> Hence my request for tools to (easily) see what's going on.
>
> *Something* is hitting the drive.


*Your* words reminded that I suspected a website of repeatedly poking
my exterior hard drive when it had no business doing so. I was just
about to poke Brian Krebs (KrebsOnSecuirty) and ask him to test if
that's what was going on, but that behavior ceased when the
potentially offending website was redesigned...

For my instances, the drive was mounted but very idle... except for
those times the light would start beaconing when I landed on that one
consumer website.....

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#206495

On Fri, Mar 22, 2019 at 04:23:32PM -0400, deb wrote:
>
>On 3/22/19 4:07 PM, Michael Stone wrote:
>>On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
>>>If you're really worried, first remount the partitions readonly, which
>>>will fail if they're in use. Then unmount them and disconnect.
>>
>>Just unmount--that will fail if the partition is in use unless extra 
>>options are added.
>>
>>Mike Stone
>>
>>
>
>Actually no.

Actually, yes. 

>That's where I started at.
>
>
>A given drive should behave the same on Windows & Linux as far as 
>lights on/off/dimming.
>
>But as I noted earlier, on Windows, the light is OFF, signaling no 
>drive activity upon being removed.
>
>On debian 9.8, it stays on, after repeated dismounts.

Then there's nothing using the drive and you're barking up the wrong 
tree.

What you're seeing is that windows does a disconnect if you're using the 
"safely remove" thing. You might be able to get the same effect in linux 
by running "eject" on the drive, depends on what specifically the drive 
is looking for.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#206505

On 3/22/19 7:39 PM, Michael Stone wrote:
> On Fri, Mar 22, 2019 at 04:23:32PM -0400, deb wrote:
>>
>> On 3/22/19 4:07 PM, Michael Stone wrote:
>>> On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
>>>> If you're really worried, first remount the partitions readonly, which
>>>> will fail if they're in use. Then unmount them and disconnect.
>>>
>>> Just unmount--that will fail if the partition is in use unless extra 
>>> options are added.
>>>
>>> Mike Stone
>>>
>>>
>>
>> Actually no.
>
> Actually, yes.
>> That's where I started at.
>>
>>
>> A given drive should behave the same on Windows & Linux as far as 
>> lights on/off/dimming.
>>
>> But as I noted earlier, on Windows, the light is OFF, signaling no 
>> drive activity upon being removed.
>>
>> On debian 9.8, it stays on, after repeated dismounts.
>
> Then there's nothing using the drive and you're barking up the wrong 
> tree.
>
> What you're seeing is that windows does a disconnect if you're using 
> the "safely remove" thing. You might be able to get the same effect in 
> linux by running "eject" on the drive, depends on what specifically 
> the drive is looking for.
>
> Mike Stone
>
>


I had previously tried eject as well.

Hard light was still on.

My choice was shutdown and pull the cable or pull it out seemingly hot.


Hopefully the tool choices from the others will provide info.

[toc] | [prev] | [next] | [standalone]

#206508

On Fri 22 Mar 2019 at 21:19:19 (-0400), deb wrote:
> On 3/22/19 7:39 PM, Michael Stone wrote:
> > On Fri, Mar 22, 2019 at 04:23:32PM -0400, deb wrote:
> > > On 3/22/19 4:07 PM, Michael Stone wrote:
> > > > On Fri, Mar 22, 2019 at 03:00:23PM -0500, David Wright wrote:
> > > > > If you're really worried, first remount the partitions readonly, which
> > > > > will fail if they're in use. Then unmount them and disconnect.
> > > > 
> > > > Just unmount--that will fail if the partition is in use
> > > > unless extra options are added.
> > > 
> > > Actually no.
> > 
> > Actually, yes.
> > > That's where I started at.
> > > 
> > > A given drive should behave the same on Windows & Linux as far
> > > as lights on/off/dimming.

I don't think the difference is in the behaviour of the drive, but in
the behaviour of whatever it's plugged into.

> > > But as I noted earlier, on Windows, the light is OFF,
> > > signaling no drive activity upon being removed.
> > > 
> > > On debian 9.8, it stays on, after repeated dismounts.

Yes. Presumably you had to mount it between each dismount.
(You can't unmount something that's not mounted.)

In Windows, after you have Safely Removed the drive with the menu,
try leaving the drive plugged in. Now mount it again. Can you?
You could in linux.

> > Then there's nothing using the drive and you're barking up the
> > wrong tree.
> > 
> > What you're seeing is that windows does a disconnect if you're
> > using the "safely remove" thing. You might be able to get the same
> > effect in linux by running "eject" on the drive, depends on what
> > specifically the drive is looking for.
> 
> I had previously tried eject as well.
> 
> Hard light was still on.
> 
> My choice was shutdown and pull the cable or pull it out seemingly hot.

Is that a problem? USB was designed for hot plugging and unplugging.
In fact, some systems won't recognise that a device is present unless
it is plugged in hot, eg my AiO Printer.

> Hopefully the tool choices from the others will provide info.

If those tools are looking for activity, they won't find any.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#206482 — Re: Curt --- Re: iotop - or, checking what is accessing a drive

On Fri 22 Mar 2019 at 14:00:24 (-0400), deb wrote:
> On 3/22/19 1:48 PM, Curt wrote:
> > On 2019-03-22, deb <deb@rangingthoughts.org> wrote:
> > > > Depending on what's on the disk, it might be more useful to just use
> > > > lsof to see what files are open and try to understand what those might
> > > > be doing.

> > I believe you said that the external USB drive's LED remains on, even
> > after unmounting, and that indicates to you that there's activity on the
> > drive. I've always labored under the idea that a *flashing* light
> > indicated activity and a steady one an idle state.
> > 
> > Now it occurs to me that these signal indications may depend on the make
> > and model of the drive itself.
> > 
> > What should be the behavior of the LED on your drive when the drive is
> > unmounted and/or inactive?

> YES -- this differs by manufacturer.

… and by model, in the case of Seagate.

> Just a reminder -- the bulk of mine are Seagate Backup Plus (1-5TB.
> USB 3.0).
> On Windows, when you dismount (Safely Remove) these
> the light goes off.

I've never seen the light go off until it spins down (those that do).

> It is On when connected and very dimmly flashed when being accessed.
> So, it can flash a bit when indexes are up[dated,
> or a file is flushed -- and go right back to steady on.

My 5TB doesn't ever flash or dim; a little annoying.

> I only *feel* safe, pulling the cable when the light is OFF.

If you're really worried, first remount the partitions readonly, which
will fail if they're in use. Then unmount them and disconnect.

> Again, I can NOT suffer a data-loss-because-of-Evil-Linux situation,
> giving the Windows-folk ammo.

Disks occasionally fail for everyone, irrespective of OS.

> I wanted to switch to your name in the Subject Curt,
> but Jim P. will yell at me. :-)
> 
> 
> Screw it --- I switched it anyway.

I can already see whose post yours is commenting on. The rule is simple:
Change the subject line if the subject changes,
Don't change the subject line if the subject doesn't change.

On a technical point, there are those whose less functional
mail clients thread by subject line rather than Message-ID.
Their threading get totally fragmented by all your changes.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web