Message-ID: <43F74C89.1080606@cfl.rr.com>
Date: Sat, 18 Feb 2006 11:34:17 -0500
From: Phillip Susi <psusi@cfl.rr.com>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: Pavel Machek <pavel@suse.cz>
CC: Alan Stern <stern@rowland.harvard.edu>, Kyle Moffett <mrmacman_g4@mac.com>,
       Alon Bar-Lev <alon.barlev@gmail.com>,
       Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Flames over -- Re: Which is simpler?
References: <Pine.LNX.4.44L0.0602131601220.4754-100000@iolanthe.rowland.org> <43F11A9D.5010301@cfl.rr.com> <20060217210445.GR3490@openzaurus.ucw.cz>
In-Reply-To: <20060217210445.GR3490@openzaurus.ucw.cz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1626
Lines: 38

Pavel Machek wrote:
> 
> Must?! Are you Linus or what?
> 

Non sequitur.

> 
> You are missing this. In 1st case, no data is actually lost, because of
> sync in suspend code;
> while second case is "goodbye, filesystem".

Provided that you sync before suspending, and there are no open files on 
the filesystem, then yes, no data will be lost.  If there are open files 
on the fs, such as a half saved document, or a running binary, or say, 
the whole root fs, then you're going to loose data and even panic the 
kernel, sync or no sync.  From the user perspective, this is unacceptable.


Why should the user give up such functionality just because the 
connection to the drive thy are using is USB?  Every other type of drive 
and interface does not suffer from this problem.

Maybe Linux should take a page from windows' playbook here.  I believe 
windows handles this scenario with a USB drive the same way it does when 
you eject a floppy and reinsert it.  The driver detects that the 
media/drive _may_ have changed and so it fails requests from the 
filesystem with an error code indicating this.  The filesystem then sets 
an override flag so it can send down some reads to verify the media. 
Generally the FS reads the super block and compares it with the in 
memory one to make sure it appears to be the same media, and if so, 
continues normal access without data loss.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/