From owner-freebsd-mobile@FreeBSD.ORG Mon Sep 20 23:20:51 2004 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AB2116A4CF for ; Mon, 20 Sep 2004 23:20:51 +0000 (GMT) Received: from web42301.mail.yahoo.com (web42301.mail.yahoo.com [66.218.93.210]) by mx1.FreeBSD.org (Postfix) with SMTP id 072CA43D46 for ; Mon, 20 Sep 2004 23:20:51 +0000 (GMT) (envelope-from jd10008@yahoo.com) Message-ID: <20040920232050.81796.qmail@web42301.mail.yahoo.com> Received: from [207.88.90.254] by web42301.mail.yahoo.com via HTTP; Mon, 20 Sep 2004 16:20:50 PDT Date: Mon, 20 Sep 2004 16:20:50 -0700 (PDT) From: Joseph Davida To: Stefan "Eßer" In-Reply-To: <20040920204151.GB4299@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Christopher Sean Hilton cc: User Jhs cc: freebsd-mobile@freebsd.org Subject: Re: How to get usbd to umount fle systems without crashing ? X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 23:20:51 -0000 Providing an FS option to mount such devices with all synchronous updates (data and metadata) is a much safer and easier. All that you would need here is that unplugging the device would trigger an event which would lead to unmounting the device automatically with a much lesser chance of losing any data from unwritten buffers belonging to the device. Data could still be lost if say you were copying large files from some other drive to the USB stick device. Of course, if processes had open file descriptors in such a filesystem , an unplug event should be handled by returning an error to all processes with open file descriptors that attempt to read/write such files, but should still lead to unmonting the device. Seems to me the scheme you describe requires yet another facility in the kernel to monitor activity (or inactivity) of a filesystem, change the superblock fs structure contents (fs->fs_ronly)...etc which would require yet another slowdown in the kernel: i.e. synchronizing with processes. I imagine it would require that a kernel watchdog timer (which would set the FS to RO) synchronize with the sync()er, softupdates, the pagedaemon, the bufdaemon, and possibly others, in order to implement the safe transition of fs_ronly from 0 to 1, and back again from 1 to 0. Also, what if the device is mounted read only for the purpose that no one should modify it's files? The scheme you describe, even if it were cleanly implementable, would override that and defeat the purpose. My $.02's worth :) Cheers, Joe --- Stefan Eßer wrote: > On 2004-09-20 10:49 -0700, Joseph Davida wrote: > > For these devices (memory sticks), a new > > option to mount is needed. > > Currently the default mount is > > noasync. From mount(8) man page: > > noasync > > Metadata I/O should be done synchronously, > > while data I/O should be done asynchronously. > > This is the default. > > > > What we need is an option like "noasynchdata" > > or "synchdata" to force all IO (data and metadata) > > to be synchronous to these USB memory sticks. > > This will enable us to hot unplug a memory stick > > and the OS should automatically unmount > > the device (I dont know if automatic umount > > is currently implemented). > > I'd often wanted to have an option that re-mounts a drive R/O after > some period of inactivity (say, one to three seconds), and which > switches back to a R/W for the next write request. An implicit fsync > of all files open for writing on that device is required (which may > possibly restart the time-out, if (meta-)data has to be written). > > Different from an "mount -u -r" is that files may still be open for > writing (next write to the device should immediately cause the in-core > superblock to be marked dirty again and to be written to disk). > > The intent is to mount any removable media (USB stick, hot-pluggable > disk drive, floppy) with that option and to have the filesystem > super-block marked clean as soon as the device has not been written to > for a few seconds. > > I have not thoroughly looked at the complexity of implementing such a > filesystem option, but I guess that most of the functionality is already > there: > > An implementation could consist of a time-out handler that calls VFS_SYNC > when there haven't been any writes during the configured period of time. > > Initially and as long as the super-block is marked clean, fs->fs_ronly > should be set. > > In the error handler that is invoked when attempting to write to a R/O > filesystem, the new mount option should be checked, causing an update to > R/W and the start of the time-out mechanism that will eventually cause > the downgrade to R/O, completing one iteration of the loop. > > During an attempt to upgrade the mount to R/W, the super-block must be > verified to match the actual device (it could have been exchanged). In > case of a mis-match (or the device or media having been removed), a forced > unmount of the filesystem is required, which will cause all further attempts > to read or write files on that filesystem to fail. > > Did I miss anything? > > Regards, STefan > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail