On Fri, Apr 08, 2005 at 12:10:45PM -0700, Marcel Moolenaar wrote: > o Editing the in-core data is an immediate show-stopper. You > immediately pull the root file system from under the running > OS. Not good, no matter what the failure mode. Yes. > o Editing the on-disk data is harmless as long as you don't > sync in the in-core data with the disk. It's a showstopper > when you do sync. The advantage is clear. You can have non- > atomic operations that are dangerous, harmful or inconsistent > when partly applied, but that may yield a harmless change > when fully completed. Yes. > The same applies to any and all changes. I mainly mean on-disk->in-core sync moment in your scheme. If, by some reason, automatic or unexpected or by mistake, such sync happens, it is immediate show-stopper. But in my scheme where only in-core->on-disk sync exists, most unpleasant sytuation, if such sync will happens automatic or unexpected or by mistake, was lost on-disk surgery changes, which is far less painful. > I see. Do you think it's wise to design for broken file system > implementations? Don't you think that it's fair to assume that It was just one real example which not worth to discuss in its particuar details. Lets go to higher level of which this example should illustrate. The higher level is: sometimes something happens which needs to make artificial changes in the on-disk (not in-core) partition, disklabel or boot, usually temporary in nature. > > For surgery purposes. Consider this like fsdb(8). > > I look at it from a much more elementary point of view: if you > do surgery that crosses partition boundaries, then you need to > be doing raw disk access and no partition table is prohibiting > you therein. Why then is there a need to change the partition > table? Not all situations are so bad so only raw disk access can handle them, some of them can be fixed with less pain using unrestricted standard partition/disklabel/boot editing tools. > I see. I think this is another point on which we differ: you want > to be able to edit the partition table to accomodate certain kinds > of surgery. I think such surgery doesn't need support from the > tools as it goes well beyond the functionality of partitioning. Before GEOM I was able to use hex editor to edit disk directly too (now GEOM prevents even that). But editing those things with special tool is far more convenient that manualy compute all offsets and find needed bytes. Old fdisk-like tools in many OSes was more admin-friendly because not have new wave restrictions to prevent novices to do something wrong. All strictness here is recent innovation which makes admin life harder. For the sake of unknow newbies: Tom, Jerry, etc. I suggest the compromise between this two methods: when the changes are inconsistens, on-disk editing tool can complain as loudly and verbosily as it can (warnings, confirmations, etc.) but not finally prevent modification. Because human knows better, what machine needs. -- http://ache.pp.ru/Received on Fri Apr 08 2005 - 19:04:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC