Date: Sat, 24 Dec 2011 00:21:02 +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: <20111223232102.GA20961@slackbox.erewhon.net> In-Reply-To: <4EF4FAAA.1020603@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 24, 2011 at 08:03:22AM +1000, Da Rock wrote: > > If the network goes down, network drives won't work. Your users will be > > sad/scared/frustrated with or without error messages, I'm guessing. > Nah. They'd flip out a whole lot more when the screen literally fills=20 > with error messages and keeps going. Frustrated they can handle and=20 > maybe complain, but that would make them run away... :) Wouldn't you get some error message or other if a network drive becomes unreachable no matter what?=20 > > Another way to go about it is to install e.g. ubuntu on a virtual machi= ne and > > peek under the hood how it works there. But as you say it's probably ti= ed into > > udev pretty tightly. > Tried that too, but each distro has there own "hack" to make it work for= =20 > them. Crazy huh? I tried ubuntu once in a VM (I was a slackware user before moving to FreeBSD). Had a quick look with ps and was rather appalled at all the stuff that was running with no obvious way to turn it off. > > Devd just gets some notifications and acts on them. There is a problem = with > > mounted usb devices, but that is one of architecture, I guess. Devd onl= y gets > > notified _after_ a device has been pulled. There is no way you can prev= ent > > data loss in all cases like that. On windows you're supposed to "prepar= e to > > eject" a USB device before pulling it out as well. The only "cure" is t= o mount > > a device syncronously, and disable _all_ write caching for those device= s. If > > you try that you'll find that doing so has significant performance impa= ct and > > not in a good way (disks are sloooow). > Almost need a "journaling" system for them. Any thoughts? What about=20 > setting up a temp folder (non-volatile buffer?) and a sync? Track=20 > devices using the uuid label? With proper mount settings and synchronous writes you might be able to prev= ent most damage, but it'll be slow. The default for mount is to write metadata syncronously, while data I/O is done async, see mount(8). No matter what you do, if a user pulls a USB stick during a write, the filesystem on it will be left in an inconsistent state. Nothing you can do about that. 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 ev= en 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... Basically if a USB drive is plugged back in again, you have to accept the state that it is in at that time. You cannot assume that it's state is still the same or even related as the last time it was plugged in. But suppose for the sake of the argument that you have a complete and correct copy of the U= SB stick's filesystem at the time it was pulled buffered. Now assume the same device is plugged in again. You read the complete state of the filesystem a= nd compare it to your buffer. Suppose there is a difference between the two. W= hat are you going to do? Without further information there is no way of knowing which of the changes are OK because they were done e.g. on another computer. And there is the application that is writing that is to be considered. With buffering enabled, write system calls return as soon as the metadata is written and the data is queued, IIRC. So as fas as the app is concerned, it= is done. Of course the next system call to write to the same fs after it is pulled will get an error. But that still leaves the application's image of = the file's state different from reality. 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 shou= ld then report to the user because that's the person that pulled the plug, so = to speak. > > submit it to the freebsd-doc mailing list for inclusion in the official= docs? > I may yet do that, but in the interim I'm going to get around to writing= =20 > up my findings on a lot of different aspects of the systems in a wiki=20 > (I'll put up my findings on those as well...). Maybe my pain can help=20 > someone else :) Please but up a link to that wiki. :-) > For reference _all_ my systems are FreeBSD: from laptops/desktops,=20 > HTPC's and servers. I'd like to be able to show a system better and more= =20 > robust than the alternatives out there as well as easy on the users, and= =20 > thats what I'm always working towards. Nice! I wish I was able to use FreeBSD at work (other than on my own laptop= ). > > And talking about mailing lists, maybe you should try your luck on the > > freebsd-gnome list? > > [http://lists.freebsd.org/mailman/listinfo/freebsd-gnome] > I would but I'm not subscribed to that one (must be about the only one=20 > I'm not on :) ), and it hadn't come to mind as I wasn't using gnome! I'm= =20 > using nautilus for testing as it has more features, but I'm intending on= =20 > using pcmanfm or similar- lightweight, but usable. 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. 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) --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk71DN4ACgkQEnfvsMMhpyXSQgCglOy5zty+dUWkKPHHFPmo0zEn AhsAn1+vyfmN+1zIEBYElUrk/CLo80hw =gUyx -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111223232102.GA20961>