Date: Sat, 24 Dec 2011 09:57:38 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: PolicyKit confusion Message-ID: <4EF51572.4060507@herveybayaustralia.com.au> In-Reply-To: <20111223232102.GA20961@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/24/11 09:21, Roland Smith wrote: > 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 >> with error messages and keeps going. Frustrated they can handle and >> 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? True, but its not so bad as a screenful- and I mean a screenful! >>> Another way to go about it is to install e.g. ubuntu on a virtual machine and >>> peek under the hood how it works there. But as you say it's probably tied into >>> udev pretty tightly. >> Tried that too, but each distro has there own "hack" to make it work for >> 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 only gets >>> notified _after_ a device has been pulled. There is no way you can prevent >>> data loss in all cases like that. On windows you're supposed to "prepare to >>> eject" a USB device before pulling it out as well. The only "cure" is to mount >>> a device syncronously, and disable _all_ write caching for those devices. If >>> you try that you'll find that doing so has significant performance impact and >>> not in a good way (disks are sloooow). >> Almost need a "journaling" system for them. Any thoughts? What about >> setting up a temp folder (non-volatile buffer?) and a sync? Track >> devices using the uuid label? > With proper mount settings and synchronous writes you might be able to prevent > 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. True. I'm only thinking of when the little light stops flashing. > 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? > 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 USB > 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 and > compare it to your buffer. Suppose there is a difference between the two. What > 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. No, I hadn't considered that scenario. Thats why these lists provide a great sounding board :) > 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 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. As a user, and watching other less literate users, thats what they're all watching for. It seems pretty simple doesn't it? Does fuse help this at all? Most are vfat or ntfs after all... If they're not, then they'd be a bit more literate anyway, surely. And if one was really anal a fuse-ufs :) >>> 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 >> up my findings on a lot of different aspects of the systems in a wiki >> (I'll put up my findings on those as well...). Maybe my pain can help >> someone else :) > Please but up a link to that wiki. :-) Absolutely. I'm hoping to find answers to the more obscure settings. I'm writing how to's or tutorials- just the variables and conf settings and the context they're used in written in english for sysadmins who don't have the time to translate for jargonese... >> For reference _all_ my systems are FreeBSD: from laptops/desktops, >> HTPC's and servers. I'd like to be able to show a system better and more >> robust than the alternatives out there as well as easy on the users, and >> thats what I'm always working towards. > Nice! I wish I was able to use FreeBSD at work (other than on my own laptop). Easy when you're your own boss... in a way anyway :) >>> 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 >> I'm not on :) ), and it hadn't come to mind as I wasn't using gnome! I'm >> using nautilus for testing as it has more features, but I'm intending on >> 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. > Ahh. Now that may explain some things. But by your meaning are you talking about the software development itself or the developers? LOL
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF51572.4060507>