From owner-freebsd-questions@FreeBSD.ORG Sat Dec 24 02:26:27 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F16DC106566B for ; Sat, 24 Dec 2011 02:26:27 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id A3A648FC0A for ; Sat, 24 Dec 2011 02:26:27 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 8310E5C24 for ; Sat, 24 Dec 2011 12:38:52 +1000 (EST) Message-ID: <4EF53795.1090409@herveybayaustralia.com.au> Date: Sat, 24 Dec 2011 12:23:17 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org 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> In-Reply-To: <20111224013458.GA25515@slackbox.erewhon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PolicyKit confusion X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 02:26:28 -0000 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 result in inconsistencies. But vfat is another kettle of fish altogether. 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... I've had some experience with async and gjournal, so it should work as I'm dreaming it :)