Re: Flames over -- Re: Which is simpler?

Re: Flames over -- Re: Which is simpler?

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2957 bytes --]

On Fri, 17 Feb 2006, Pavel Machek wrote:

> > If there is no better way to tell for sure that the device that is 
> > now there is not the same as the one that was there, then the kernel 
> > must assume the user did not do something stupid and continue to use 
> 
> Must?! Are you Linus or what?

Technical issues aside, the question about recogizing formerly-attached 
devices when waking up from a system sleep is really about 
user-friendliness.  The choice between what Phillip is advocating and what 
the rest of us have been saying is a policy choice, one that the kernel 
can't easily avoid making.

Given that this is a policy decision, it might not be such a bad idea to 
ask Andrew or Linus for their opinion.  In fact, I'll do that right now.


To summarize the background:

When a hotpluggable bus (USB for sure, possibly others as well) loses 
power, the hardware interprets this as a disconnection of all attached 
devices.  When power is restored, it appears to the kernel as though a 
completely new set of devices has now been plugged in.

This is unfriendly for people whose motherboard/USB-controller hardware
doesn't supply minimal power during hardware- or software-suspend.  Any
mounted filesystems on a USB storage device get blown away when the system
resumes, since the kernel thinks the device was unplugged.

In principle the kernel is capable of detecting that a device present on a
port during resume is very similar to the device that had been present
during the suspend.  Through a combination of checks (descriptors, serial
numbers, superblocks, maybe others) it could try to verify this and then
keep the device data structures intact, as though the device had been
connected all along.

The advantage is that people wouldn't lose half-stored data on their
removable drives, they wouldn't have unmount before suspending and remount 
after resuming, and they would be able to suspend with their root
filesystem on a USB drive without causing a panic upon resume.

The disadvantage is that sometimes people do switch removable drives or
removable media while the system is asleep.  If the kernel gets fooled
into thinking the new device is the same as the old one, it would proceed
to destroy the data on the new device by overwriting it with data from the
old one.  (Not to mention that this kind of approach is contrary to the
USB specification.)

On the other hand, it's what Windows does.  We don't want people to say 
that Linux is incapable of implementing a feature that Windows has had for 
a long time.  :-)


So the question is: What should the kernel do?  Assume the device has 
changed (as it does now) or make some checks to see if it might still be 
the same (dangerous though that may be)?

If you really want to waffle, you can recommend that the capability to do
this be present but normally disabled, controlled by a flag somewhere in
/sys/kernel -- thus pushing the decision off to userspace.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Andrew Morton]

[-- Attachment #1: Type: text/plain, Size: 4285 bytes --]

Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, 17 Feb 2006, Pavel Machek wrote:
> 
> > > If there is no better way to tell for sure that the device that is 
> > > now there is not the same as the one that was there, then the kernel 
> > > must assume the user did not do something stupid and continue to use 
> > 
> > Must?! Are you Linus or what?
> 
> Technical issues aside, the question about recogizing formerly-attached 
> devices when waking up from a system sleep is really about 
> user-friendliness.  The choice between what Phillip is advocating and what 
> the rest of us have been saying is a policy choice, one that the kernel 
> can't easily avoid making.
> 
> Given that this is a policy decision, it might not be such a bad idea to 
> ask Andrew or Linus for their opinion.  In fact, I'll do that right now.
> 
> 
> To summarize the background:
> 
> When a hotpluggable bus (USB for sure, possibly others as well) loses 
> power, the hardware interprets this as a disconnection of all attached 
> devices.  When power is restored, it appears to the kernel as though a 
> completely new set of devices has now been plugged in.
> 
> This is unfriendly for people whose motherboard/USB-controller hardware
> doesn't supply minimal power during hardware- or software-suspend.  Any
> mounted filesystems on a USB storage device get blown away when the system
> resumes, since the kernel thinks the device was unplugged.

I'm all for being friendly to people.

> In principle the kernel is capable of detecting that a device present on a
> port during resume is very similar to the device that had been present
> during the suspend.  Through a combination of checks (descriptors, serial
> numbers, superblocks, maybe others) it could try to verify this and then
> keep the device data structures intact, as though the device had been
> connected all along.
> 
> The advantage is that people wouldn't lose half-stored data on their
> removable drives, they wouldn't have unmount before suspending and remount 
> after resuming, and they would be able to suspend with their root
> filesystem on a USB drive without causing a panic upon resume.
> 
> The disadvantage is that sometimes people do switch removable drives or
> removable media while the system is asleep.  If the kernel gets fooled
> into thinking the new device is the same as the old one, it would proceed
> to destroy the data on the new device by overwriting it with data from the
> old one.  (Not to mention that this kind of approach is contrary to the
> USB specification.)
> 
> On the other hand, it's what Windows does.  We don't want people to say 
> that Linux is incapable of implementing a feature that Windows has had for 
> a long time.  :-)
> 
> 
> So the question is: What should the kernel do?  Assume the device has 
> changed (as it does now) or make some checks to see if it might still be 
> the same (dangerous though that may be)?
> 
> If you really want to waffle, you can recommend that the capability to do
> this be present but normally disabled, controlled by a flag somewhere in
> /sys/kernel -- thus pushing the decision off to userspace.
> 

Correct me if I'm wrong, but this really only affects storage devices, yes?
That narrows the scope of the problem quite some.

I suspect we could do a very good job of working out whether we're still
talking to the same fs if filesystem drivers were to help in that.

But I suspect we could do an even better job if we did that in userspace.

The logic to determine whether the new device is the same as the old device
can be arbitrarily complex, with increasing levels of success.  Various
heuristics can be applied, some of which will involve knowledge of
filesystem layout, etc.

So would it not be possible to optionally punt the device naming decision
up to the hotplug scripts?  So code up there can go do direct-IO reads of
the newly-present blockdev, use filesytem layout knowledge, peek at UUIDs,
superblocks, disk labels, partition tables, inode numbering, etc?  Go look
up a database, work out what that filesystem was doing last time we saw it,
etc?

We could of course add things to the filesystems to help this process, but
it'd be good if all the state tracking and magic didn't have to be locked
up in the kernel.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Phillip Susi]

Andrew Morton wrote:
> Correct me if I'm wrong, but this really only affects storage devices, yes?
> That narrows the scope of the problem quite some.
> 
> I suspect we could do a very good job of working out whether we're still
> talking to the same fs if filesystem drivers were to help in that.
> 

Exactly, which is why windows involves the filesystem driver.

> But I suspect we could do an even better job if we did that in userspace.
> 
> The logic to determine whether the new device is the same as the old device
> can be arbitrarily complex, with increasing levels of success.  Various
> heuristics can be applied, some of which will involve knowledge of
> filesystem layout, etc.
> 
> So would it not be possible to optionally punt the device naming decision
> up to the hotplug scripts?  So code up there can go do direct-IO reads of
> the newly-present blockdev, use filesytem layout knowledge, peek at UUIDs,
> superblocks, disk labels, partition tables, inode numbering, etc?  Go look
> up a database, work out what that filesystem was doing last time we saw it,
> etc?
> 
> We could of course add things to the filesystems to help this process, but
> it'd be good if all the state tracking and magic didn't have to be locked
> up in the kernel.


Hrm... interesting but sounds like that could be sticky.  For instance, 
what if the user script that does the verifying happens to be ON the 
volume to be verified?

I think this kind of thing is really going to have to be in kernel, like 
a remount.

Re: Flames over -- Re: Which is simpler?

[Andrew Morton]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Phillip Susi <psusi@cfl.rr.com> wrote:
>
> > But I suspect we could do an even better job if we did that in userspace.
>  > 
>  > The logic to determine whether the new device is the same as the old device
>  > can be arbitrarily complex, with increasing levels of success.  Various
>  > heuristics can be applied, some of which will involve knowledge of
>  > filesystem layout, etc.
>  > 
>  > So would it not be possible to optionally punt the device naming decision
>  > up to the hotplug scripts?  So code up there can go do direct-IO reads of
>  > the newly-present blockdev, use filesytem layout knowledge, peek at UUIDs,
>  > superblocks, disk labels, partition tables, inode numbering, etc?  Go look
>  > up a database, work out what that filesystem was doing last time we saw it,
>  > etc?
>  > 
>  > We could of course add things to the filesystems to help this process, but
>  > it'd be good if all the state tracking and magic didn't have to be locked
>  > up in the kernel.
> 
> 
>  Hrm... interesting but sounds like that could be sticky.  For instance, 
>  what if the user script that does the verifying happens to be ON the 
>  volume to be verified?

Well that would be a bug.  Solutions would be a) don't put the scripts on a
removable/power-downable device or b) use tmpfs.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Phillip Susi]

Andrew Morton wrote:
>>
>>  Hrm... interesting but sounds like that could be sticky.  For instance, 
>>  what if the user script that does the verifying happens to be ON the 
>>  volume to be verified?
> 
> Well that would be a bug.  Solutions would be a) don't put the scripts on a
> removable/power-downable device or b) use tmpfs.
> 

I don't see how it could be a bug, just think of the root on usb case. 
Keeping the program locked in ram would sidestep that issue, but tmpfs 
is pagable right?  Swap on usb?

Also, this user space program isn't going to be able to keep fully up to 
date on what the disk looks like.  Imagine a filesystem that keeps a 
generation counter in the super block and increments it every time it 
writes to the disk.  The user space daemon might read that, then the fs 
changes it, you suspend, and when you wake up, the daemon thinks the 
media changed because it wasn't fully up to date.

Re: Flames over -- Re: Which is simpler?

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1858 bytes --]

On Sun, 19 Feb 2006, Phillip Susi wrote:

> Andrew Morton wrote:
> >>
> >>  Hrm... interesting but sounds like that could be sticky.  For instance, 
> >>  what if the user script that does the verifying happens to be ON the 
> >>  volume to be verified?
> > 
> > Well that would be a bug.  Solutions would be a) don't put the scripts on a
> > removable/power-downable device or b) use tmpfs.
> > 
> 
> I don't see how it could be a bug, just think of the root on usb case. 
> Keeping the program locked in ram would sidestep that issue, but tmpfs 
> is pagable right?  Swap on usb?
> 
> Also, this user space program isn't going to be able to keep fully up to 
> date on what the disk looks like.  Imagine a filesystem that keeps a 
> generation counter in the super block and increments it every time it 
> writes to the disk.  The user space daemon might read that, then the fs 
> changes it, you suspend, and when you wake up, the daemon thinks the 
> media changed because it wasn't fully up to date.

There are other, harder problems associated with doing this is userspace.

Really, the device needs to be considered separately at each level of
driver processing.  At the USB level it may still appear to be the same,
but at the SCSI level it may appear different.  Or at the SCSI level it
may be the same, but at the gendisk level it may be different (different
media, partition table changed).  Or at the gendisk level it may be the
same, but at the filesystem level one or more of the partitions may be
different (superblock changed).

Each level would need its own way of checking for changes and recreating 
the appropriate data structures.  And while making the determinations, we 
would need to temporarily set the device to read-only.  Yes, userspace 
could do _some_ of the work, but it would need a lot of help from the 
kernel.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Andrew Morton]

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Sun, 19 Feb 2006, Phillip Susi wrote:
> 
> > Andrew Morton wrote:
> > >>
> > >>  Hrm... interesting but sounds like that could be sticky.  For instance, 
> > >>  what if the user script that does the verifying happens to be ON the 
> > >>  volume to be verified?
> > > 
> > > Well that would be a bug.  Solutions would be a) don't put the scripts on a
> > > removable/power-downable device or b) use tmpfs.
> > > 
> > 
> > I don't see how it could be a bug, just think of the root on usb case. 
> > Keeping the program locked in ram would sidestep that issue, but tmpfs 
> > is pagable right?  Swap on usb?
> > 
> > Also, this user space program isn't going to be able to keep fully up to 
> > date on what the disk looks like.  Imagine a filesystem that keeps a 
> > generation counter in the super block and increments it every time it 
> > writes to the disk.  The user space daemon might read that, then the fs 
> > changes it, you suspend, and when you wake up, the daemon thinks the 
> > media changed because it wasn't fully up to date.
> 
> There are other, harder problems associated with doing this is userspace.
> 
> Really, the device needs to be considered separately at each level of
> driver processing.  At the USB level it may still appear to be the same,
> but at the SCSI level it may appear different.  Or at the SCSI level it
> may be the same, but at the gendisk level it may be different (different
> media, partition table changed).  Or at the gendisk level it may be the
> same, but at the filesystem level one or more of the partitions may be
> different (superblock changed).
> 
> Each level would need its own way of checking for changes and recreating 
> the appropriate data structures.  And while making the determinations, we 
> would need to temporarily set the device to read-only.  Yes, userspace 
> could do _some_ of the work, but it would need a lot of help from the 
> kernel.
> 

There are two things here: a) identifying the device and b) putting it into
the correct place in the various data structures.  I suspect these can (and
should) be separated out.

For a), the current kernel behaviour is what we want - make the thing
appear at a new place in the namespace and in the hierarchy.  Then
userspace can do whatever needs to be done to identify the device, and
apply some sort of policy decision to the result.

It's what comes next that we're missing: the ability for userspace to tell
the krnrel what the decice's naming and positioning _should_ be.  The
kernel will then atomically tear down what it currently has and will then
set everything up as desired.


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Oliver Neukum]

Am Sonntag, 19. Februar 2006 21:02 schrieb Andrew Morton:
> For a), the current kernel behaviour is what we want - make the thing
> appear at a new place in the namespace and in the hierarchy.  Then
> userspace can do whatever needs to be done to identify the device, and
> apply some sort of policy decision to the result.

How? If you have a running user space the connection to the open files
is already severed, as any access in that time window must fail.
For the rest we have udev.

	Oliver

Re: Flames over -- Re: Which is simpler?

[Andrew Morton]

Oliver Neukum <oliver@neukum.org> wrote:
>
> Am Sonntag, 19. Februar 2006 21:02 schrieb Andrew Morton:
> > For a), the current kernel behaviour is what we want - make the thing
> > appear at a new place in the namespace and in the hierarchy.  Then
> > userspace can do whatever needs to be done to identify the device, and
> > apply some sort of policy decision to the result.
> 
> How? If you have a running user space the connection to the open files
> is already severed, as any access in that time window must fail.

That's a separate issue, which we haven't discussed yet.  We have a device
which has gone away and which might come back later on.  Presently we will
return an I/O error if I/O is attempted in that window.  Obviously we'll
need to do something different, such as block reads and block or defer writes.

So an overall picture would be something like:

- When device is not present, reads block and writes are deferred or block

- When device appears (at a new point in the namespace) the hotplug
  scripts will go off and will identify it and will apply some policy based
  upon that identification.  That policy could be one of:

  a) accept device at its new address

  b) accept device at its new address, abandon the old address (all
     those blocked reads and writes suddenly return -EIO).

  c) remove device from its new address, splice it back to where it
     used to be, permit those blocked reads and writes to proceed.

- For devices which are absent-and-blocked, provide some ability for both
  a timeout and manual cancellation, to unblock all those readers and
  writers, make them get -EIO.

The number of potential races is, of course, huge.

Re: Flames over -- Re: Which is simpler?

[Oliver Neukum]

Am Sonntag, 19. Februar 2006 22:02 schrieb Andrew Morton:
> Oliver Neukum <oliver@neukum.org> wrote:
> >
> > Am Sonntag, 19. Februar 2006 21:02 schrieb Andrew Morton:
> > > For a), the current kernel behaviour is what we want - make the thing
> > > appear at a new place in the namespace and in the hierarchy.  Then
> > > userspace can do whatever needs to be done to identify the device, and
> > > apply some sort of policy decision to the result.
> > 
> > How? If you have a running user space the connection to the open files
> > is already severed, as any access in that time window must fail.
> 
> That's a separate issue, which we haven't discussed yet.  We have a device
> which has gone away and which might come back later on.  Presently we will
> return an I/O error if I/O is attempted in that window.  Obviously we'll
> need to do something different, such as block reads and block or defer writes.

But how do you handle memory management?
If you simply block writes, the system will stall random tasks laundering
pages, including those needed to make progress. Even syncing before
suspend won't help you, as a running user space may dirty pages.
And what about the rootfs?

	Oliver

Re: Flames over -- Re: Which is simpler?

[Andrew Morton]

Oliver Neukum <oliver@neukum.org> wrote:
>
> Am Sonntag, 19. Februar 2006 22:02 schrieb Andrew Morton:
> > Oliver Neukum <oliver@neukum.org> wrote:
> > >
> > > Am Sonntag, 19. Februar 2006 21:02 schrieb Andrew Morton:
> > > > For a), the current kernel behaviour is what we want - make the thing
> > > > appear at a new place in the namespace and in the hierarchy.  Then
> > > > userspace can do whatever needs to be done to identify the device, and
> > > > apply some sort of policy decision to the result.
> > > 
> > > How? If you have a running user space the connection to the open files
> > > is already severed, as any access in that time window must fail.
> > 
> > That's a separate issue, which we haven't discussed yet.  We have a device
> > which has gone away and which might come back later on.  Presently we will
> > return an I/O error if I/O is attempted in that window.  Obviously we'll
> > need to do something different, such as block reads and block or defer writes.
> 
> But how do you handle memory management?
> If you simply block writes, the system will stall random tasks laundering
> pages, including those needed to make progress. Even syncing before
> suspend won't help you, as a running user space may dirty pages.

Well of _course_ that will happen.  If we have dirty pages we need to
either keep them in memory or lose them.  If someone wants to run a massive
memory stresstest, unplug the disks in the middle of it and have the
machine serenely sail along as if nothing happened then they're being
unreasonable.

> And what about the rootfs?

If you disconnect that then everything stops until you reconnect it, provided
all the tools needed to handle the reconnect are in the correct place - if
the system providers got that wrong then the machine is obviously toast.

Your questions boil down to "what if the user is crazy or the implementation
is buggy?".   Let's assume neither is true, OK?

Re: Flames over -- Re: Which is simpler?

[Andrew Morton]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Andrew Morton <akpm@osdl.org> wrote:
>
>  > If you simply block writes, the system will stall random tasks laundering
>  > pages, including those needed to make progress. Even syncing before
>  > suspend won't help you, as a running user space may dirty pages.
> 
>  Well of _course_ that will happen.

Actually, it won't happen.  There's already logic in there to help pdflush,
kswapd and memory-allocating tasks avoid blocking on congested queues. 
It's trivial to extend that to avoidance of hotunplugged queues.

Things like sync(), fsync(), O_SYNC and reads will necessarily block.

We may or may not decide to block on page-dirtyings.  Again, that's trivial
to do in balance_dirty_pages().

Race conditions are pretty much unavoidable - if someone goes and disables
a device when we're partway through and committed to I/O submission then
things will get very sticky.  But we can have a pretty successful solution
to all of this without a ton of effort.

But this is all the easy part.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1765 bytes --]

On Mon, 13 Feb 2006, Rafael J. Wysocki wrote:

> Hi,
> 
> On Monday 13 February 2006 22:24, Alan Stern wrote:
> > On Mon, 13 Feb 2006, Phillip Susi wrote:
> }-- snip --{
> > You are complaining because you don't like the way USB was designed.  
> > That's fine, but it leaves you advocating a non-standardized position.
> > 
> > Can you suggest a _reliable_ way to tell if the USB device present at a 
> > port after resuming is the same device as was there before suspending?
> 
> It seems to follow from your discussion that if I have a mounted filesystem
> on a USB device and I suspend to disk, I can lose data unless the filesystem
> has been mounted with "sync".

That's right.  It depends on your hardware, and it could be true even for
suspend-to-RAM.  In fact, even with "-o sync" you can lose data if your
programs have information in buffers they haven't written out to disk.

If you're lucky, your hardware will support low-power modes for USB
controllers while the system is asleep.  Lots of hardware doesn't,
however.  Shutting off the power to a USB controller is equivalent to 
unplugging all the attached devices.

Remember that it's always a bad idea to unplug a disk drive containing a
mounted filesystem.  With USB that's true even when your system is asleep!
The safest thing is to unmount all USB-based filesystems before suspending 
and remount them after resuming.

> If this is the case, there should be a big fat warning in the swsusp
> documentation, but there's nothing like that in there (at lease I can't find
> it easily).
> 
> [If this is not the case, I've missed something and sorry for the noise.]

I'm not aware of any warnings about this in the documentation.  If you 
would like to add something, please go ahead.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Rafael J. Wysocki]

Hi,

On Tuesday 14 February 2006 20:26, Alan Stern wrote:
> On Mon, 13 Feb 2006, Rafael J. Wysocki wrote:
> > On Monday 13 February 2006 22:24, Alan Stern wrote:
> > > On Mon, 13 Feb 2006, Phillip Susi wrote:
> > }-- snip --{
> > > You are complaining because you don't like the way USB was designed.  
> > > That's fine, but it leaves you advocating a non-standardized position.
> > > 
> > > Can you suggest a _reliable_ way to tell if the USB device present at a 
> > > port after resuming is the same device as was there before suspending?
> > 
> > It seems to follow from your discussion that if I have a mounted filesystem
> > on a USB device and I suspend to disk, I can lose data unless the filesystem
> > has been mounted with "sync".
> 
> That's right.  It depends on your hardware, and it could be true even for
> suspend-to-RAM.  In fact, even with "-o sync" you can lose data if your
> programs have information in buffers they haven't written out to disk.
> 
> If you're lucky, your hardware will support low-power modes for USB
> controllers while the system is asleep.  Lots of hardware doesn't,
> however.  Shutting off the power to a USB controller is equivalent to 
> unplugging all the attached devices.
> 
> Remember that it's always a bad idea to unplug a disk drive containing a
> mounted filesystem.  With USB that's true even when your system is asleep!
> The safest thing is to unmount all USB-based filesystems before suspending 
> and remount them after resuming.

Still, this may be impossible if the box is suspending because of its
battery running critical.

I'm afraid this behavior will cause support problems to appear in the long
run.   [BTW, I wonder if it's USB-only, or some other subsystems behave
in a similar way, like ieee1394 or external SATA.  And how about
NFS/CIFS/whatever network filesystems mounted on the suspending box?]

I think one solution to consider could be to add an abstract fs layer
on top of the removable filesystem, like subfs in SuSE, with the ability
to retain the user information accross device disconnects and to update
the fs state from the actual device when it reappears in the system and
to resolve possible conflicts (to a reasonable extent).

> > If this is the case, there should be a big fat warning in the swsusp
> > documentation, but there's nothing like that in there (at lease I can't find
> > it easily).
> > 
> > [If this is not the case, I've missed something and sorry for the noise.]
> 
> I'm not aware of any warnings about this in the documentation.  If you 
> would like to add something, please go ahead.

I'm going to do this.  Can I use your explanation above?

Rafael

Re: Flames over -- Re: Which is simpler?

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Tue, 2006-02-14 at 21:41 +0100, Rafael J. Wysocki wrote:
> [BTW, I wonder if it's USB-only, or some other subsystems behave
> in a similar way, like ieee1394 or external SATA.  And how about
> NFS/CIFS/whatever network filesystems mounted on the suspending box?]
> 

NFS is stateless, it does not care about stuff like this.  There's no
concept of an open file.  write() does not return until the data is
committed to stable storage.

Lee


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Flames over -- Re: Which is simpler?

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1718 bytes --]

On Tue, 14 Feb 2006, Rafael J. Wysocki wrote:

> > Remember that it's always a bad idea to unplug a disk drive containing a
> > mounted filesystem.  With USB that's true even when your system is asleep!
> > The safest thing is to unmount all USB-based filesystems before suspending 
> > and remount them after resuming.
> 
> Still, this may be impossible if the box is suspending because of its
> battery running critical.

Yes.  When there's nothing you can do... do nothing.  :-)

> I'm afraid this behavior will cause support problems to appear in the long
> run.   [BTW, I wonder if it's USB-only, or some other subsystems behave
> in a similar way, like ieee1394 or external SATA.  And how about
> NFS/CIFS/whatever network filesystems mounted on the suspending box?]

Some networked filesystems may have this problem, for instance, if they 
rely on some sort of keep-alive to maintain a connection.  I don't know 
anything about 1394 or SATA.

> I think one solution to consider could be to add an abstract fs layer
> on top of the removable filesystem, like subfs in SuSE, with the ability
> to retain the user information accross device disconnects and to update
> the fs state from the actual device when it reappears in the system and
> to resolve possible conflicts (to a reasonable extent).

Maybe.  To me this seems an unavoidable policy decision that should be 
settled by one of the big Linux panjandrums.  Maybe someone can convince 
Andrew (or even Linus) to offer a ruling...

> > I'm not aware of any warnings about this in the documentation.  If you 
> > would like to add something, please go ahead.
> 
> I'm going to do this.  Can I use your explanation above?

Feel free to use it.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]