Date: Sat, 24 Dec 2011 12:03:30 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: PolicyKit confusion Message-ID: <4EF532F2.6000303@herveybayaustralia.com.au> In-Reply-To: <20111224013458.GA25515@slackbox.erewhon.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <snip> > It is a heck of a problem. Distributed filesystems like Coda > [http://en.wikipedia.org/wiki/Coda_%28file_system%29] might offer a partial > solution. But it doesn't seem like they're being widely used. > >>> The only sane way to handle this is for the application to get an error from >>> the next write reporting that the filesystem has disappeared. Which it should >>> then report to the user because that's the person that pulled the plug, so to >>> speak. >> Man, What a mess! The real solution is to keep the light flashing until >> all the data written to disk. > The abovementioned -o sync option will do that for you. > > The price is that the write syscall will block until it is finished. This > might render the application performing it unresponsive during that time. Bingo! Thats exactly the issue. Taking a look at FUSE I can see there are calls that FUSE_FSYNC which I would say is the closest to what is needed. The question is are they implemented in say fuse_msdosfs (I may have just barfed that, but you get the idea) and maybe some others? That way the filesystem is treated as normal, the app writes and can return happily, and FUSE takes the responsibility to ensure the data continues to write until finished instead of holding it in buffer for an indeterminate period leaving the user thinking alls well (ergo, the light continues flashing). Failing that, how does one ensure data is synced manually? Is there a call that could be run periodically at a shorter, more regular intervals? Either that or something that just tells the disk to keep flashing its little led while the buffer is not empty :) >>> All the mayor players in this drama, hal, policykit and dbus are maintained by >>> gnome@. In practice that _might_ mean that no single person cares enough to >>> care and feed them. >>> >> Ahh. Now that may explain some things. But by your meaning are you >> talking about the software development itself or the developers? LOL > What I mean here is that there are no dedicated maintainers for the FreeBSD > ports. When that is the case, that maintainer address of a port is usually > that of a relevant mailing list. That way problems with such a port at least > get the attention of people with relevant interests. > > As for the original developers, who knows? IMNSHO their solutions look overly > complex, Indeed. At least from a BSD perspective, anyway. Linux is whole other animal... family, xenotype even :) Too many chiefs and not enough indians over there I reckon. In my mind reading your comments I was imagining some starving, malnourished developers trying to build these complex software designs surrounded by some Doc Brown-like inventions in the dungeons of Novell or something... :) Hell, it could even be the dungeons of Microsoft, with Gates uttering "Now I'll get you all, and your little dog too.." :D > And I'm kind of allergic to desktop > environments. Over the years I've tried several window managers, but I keep > coming back to good old FVWM. :-) Me too- can't get away from icewm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF532F2.6000303>