PolicyKit confusion

[Da Rock]

On 12/24/11 22:08, Roland Smith wrote:
> 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. :-)
The long and the short of it is that async is bad for SU filesystems- 
others *should* be reasonably ok. I'd have to check on NTFS.
>> 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.
You said that was slower too.
> 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
> longer.
All valid points. What it boils down to is if you yank the power or the 
disk during write you're screwed no matter what fancy tricks you play- 
include hal/dbus/blah! bull crap. The main difference is the use of 
async or sync: you either screw up with one file or a few.

You have tickled my imaginationings again, and I have an idea to throw 
at the gurus on the list (including you Roland): Assuming null/void 
computer literacy, and the use of a DE; what if one had an (can't be a 
script can it - pointless. Thinking on the fly here...) applet? dock 
notifier? that indicated the disk was in use and not to remove - 
primarily for a "blinkered" user that is missing the flashing led on the 
drive (or one missing an led)? Stays on top, flashing on the screen. Use 
mount -d to test disk status, then lets you know that it can be removed. 
I still have to test this, but I thought I'd throw it out there.

Basically, the situation (that I have found myself in numerous times) is 
the write stops to the disk because the buffers need to reach a certain 
level before write occurs, or umount. So one can mistakenly assume that 
all is kocher and find no file when they reinsert. Files are lost that 
way, and at the least its annoying. That can still even occur with hal 
and blah blah blah.

Is this feasible though? If the user still can't pay attention to _all_ 
of that then they're not worth worrying about- can't be holding their 
hand the whole time :) Then, using devd, one can implement the 
mount/umount scripts with a quick fsck on insertion to be sure ICIE (In 
Case of Idiot Event).