rsmith at xs4all.nl
Sat Dec 24 12:09:22 UTC 2011
On Sat, Dec 24, 2011 at 12:23:17PM +1000, Da Rock wrote:
> On 12/24/11 11:34, Roland Smith wrote:
> > On Sat, Dec 24, 2011 at 09:57:38AM +1000, Da Rock wrote:
> >>> FreeBSD be default already does buffering in the VFS layer (unless you turn
> >>> that off). I don't think that adding more buffering would help. It might even
> >>> make matters worse. If data is buffered and not immediately written to the USB
> >>> stick, it will show no activity. This might even give the user a false
> >>> impression it is finished...
> >> That there is exactly the problem. Any way to prevent that though?
> > Yes. Using the '-o sync' option with mount. To the best of my understanding
> > that means that a write action will be executed immediately and that write(2)
> > will not return until it is finished.
> Just discovered something: what about async as an option? The major
> problem with async is on UFS+SU - the SU's get in the road and can
I've had problems with filesystems becoming inconsistent with
softupdates. I've disabled them on most filesystems.
> result in inconsistencies. But vfat is another kettle of fish altogether.
The mount(8) manual warns that async is dangerous because it doesn't guarantee
that the fs structure on disk stays consistent. The other side of the coin is
(as you say) that vfat doesn't have much of a structure. :-)
> I just had a brainwave and looked it up, after a google or two and
> reading the mount_msdosfs man page it is possible; but is it a solution?
> The writes are done sequentially (I think), and the app can move on
> while the system writes the disk. Unless I'm missing something here...
In my script to mount USB drives I use the following options for mount_msdosfs:
"-o noatime -o sync -o noexec -o nosuid"
And yes, that will block write calls until they're truely done. But OTOH, if
you use async, an umount will block until all data is written. So it is a
question of waiting now or waiting later. ;-) Personally I like the security
and consistency that -o sync brings. Since I mostly use cp from an xterm to
copy things to/from USB disks, it doesn't bother me when is stays busy a while
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20111224/9f2af7fe/attachment.pgp
More information about the freebsd-questions