Date: Sat, 24 Dec 2011 22:56:08 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: PolicyKit confusion Message-ID: <4EF5CBE8.3030202@herveybayaustralia.com.au> In-Reply-To: <20111224122152.GB40495@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> <4EF532F2.6000303@herveybayaustralia.com.au> <20111224122152.GB40495@slackbox.erewhon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/24/11 22:21, Roland Smith wrote: > On Sat, Dec 24, 2011 at 12:03:30PM +1000, Da Rock wrote: >>> 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? > Use the source, Luke! ;-) Believe me, I'm checking now. A lot of code though, if someone already knows the answer :) >> 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). > I'm not sure how long the defaults waits are. Normally the systems tries to > cluster writes sequenstially for improved throughput. But I'm guessing we're > talking about fractions of seconds at most. Again, browsing the source might > be useful. Also chapter 6 of "The Design and Implementation of the FreeBSD > operating system" might provide insight. I'm basing my logic on experience and not theory at this point, although I have read through most of the developer docs and studied OS design. I think it waits until it reckons it has enough to fill a sector or something, buffer full; at any rate it will halt and not do a damned thing until you tell it umount and then it goes crazy- up to a minute sometimes. This is my point about the led: a user could easily mistake this for the write to be finished and yank it when there is no file there (the one they want anyway)- then end up with a "dirty" filesystem. Its very misleading. >> 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? > The sync(1) program flushes the system's write cache. Yeeeeahh... that is supposed to be before the system halts- right? So how would it be used here? Nothing in the man says how it is used, and if it is used its system wide and not focused to a particular filesystem, whatever.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF5CBE8.3030202>