Date: Sat, 24 Dec 2011 13:08:49 +0100 From: Roland Smith <rsmith@xs4all.nl> To: Da Rock <freebsd-questions@herveybayaustralia.com.au> Cc: freebsd-questions@freebsd.org Subject: Re: PolicyKit confusion Message-ID: <20111224120849.GA40495@slackbox.erewhon.net> In-Reply-To: <4EF53795.1090409@herveybayaustralia.com.au> References: <4EF4010B.5040704@herveybayaustralia.com.au> <20111223142252.GC660@slackbox.erewhon.net> <4EF49DDB.2060609@herveybayaustralia.com.au> <20111223173139.GA7648@slackbox.erewhon.net> <4EF4FAAA.1020603@herveybayaustralia.com.au> <20111223232102.GA20961@slackbox.erewhon.net> <4EF51572.4060507@herveybayaustralia.com.au> <20111224013458.GA25515@slackbox.erewhon.net> <4EF53795.1090409@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 yo= u turn > >>> that off). I don't think that adding more buffering would help. It mi= ght even > >>> make matters worse. If data is buffered and not immediately written t= o 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 understan= ding > > that means that a write action will be executed immediately and that wr= ite(2) > > will not return until it is finished. > Just discovered something: what about async as an option? The major=20 > problem with async is on UFS+SU - the SU's get in the road and can=20 I've had problems with filesystems becoming inconsistent with softupdates. I've disabled them on most filesystems.=20 > result in inconsistencies. But vfat is another kettle of fish altogether. The mount(8) manual warns that async is dangerous because it doesn't guaran= tee 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. :-) =20 > I just had a brainwave and looked it up, after a google or two and=20 > reading the mount_msdosfs man page it is possible; but is it a solution?= =20 > The writes are done sequentially (I think), and the app can move on=20 > 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_msdo= sfs:=20 "-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 wh= ile longer. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk71wNEACgkQEnfvsMMhpyUI8ACeKd8Jzr7pgKGNXAQYtWe8Qq2P 86gAoJNKLiUGWXDSx6Ap3rEj9GNXB+U1 =cmbL -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111224120849.GA40495>