Darrick Hartman wrote: > Lonnie Abelbeck wrote: > >> On Sep 23, 2008, at 1:04 PM, David Kerr wrote: >> >> >>> Running with a unionfs setup... is there a way to get rid of the >>> notion of a key disk... why do I need a /mnt/kd in the first place? >>> (I understand why it was needed histrorically, but it doesn seems >>> necessary now on CF/unionfs setups) It just adds confusion >>> particularly to directory hierarchy. It also unnecessarily holds >>> configuration files that are unchanged from defaults. >>> >>> Thoughts? >>> David >>> > > David, > > The decision was made to retain the key disk for backwards compatibility > at the very least through the 0.6 series. It will be a mess to untangle > and may create more of a mess than removing it solves. We are talking > about it, even if not publicly. > > >> In addition, I don't use unionfs for my /mnt/kd/ directory, but rather >> a separate partition. I feel this is the most robust configuration, >> but maybe that is just me. :-) >> > > The earlier implementations (which were never official releases) had an > older version of unionfs. Since upgrading to the 2.4 version of > unionfs, it's been very reliable and consistent. The 0.6.1 images > contain a 'movekd' script which walks you through moving your key disk > files to your unionfs partition. > > >> The keydisk idea clutters the development side a little, but it is >> there, and it works, and un-cluttering runs a high risk of bugs. >> Hopefully the user benefits from a single backup/restore directory out- >> weighs the development issues. Possibly a little more work is >> required to make sure all the useful files can be saved in the /mnt/ >> kd/ path. >> >> While unionfs has been a huge benefit to astLinux, it can be quite >> confusing. Knowing whether a non-/mnt/kd/ file will be mapped to >> flash or memory is not always obvious. >> > > We've made some very huge fundamental changes from the 0.4 releases. > Unionfs was one of them. This removed the idea of having to constantly > change the mount status of the / partition. Unionfs allows storing > passwords, users etc through version updates. It overlays files on top > of the existing file structure. I would argue that backing up a single > unionfs system may be easier/cleaner since everything is in one > directory. While it's not recommended to manually modify files directly > on the unionfs partition, you can look at which files are on unionfs by > looking at /oldroot/mnt/asturw. > > Darrick >
I concur with Darrick. Currently, /oldroot/mnt/asturw isn't that different from /mnt/kd (except /mnt/kd is flat). Further, this allows not just config files, but scripts as well to be tweaked (which is fine when you know what you're doing, and less good otherwise ... :-) ) My only issue is we need a cleanup script that runs at boot before /oldroot/mnt/asturw gets run to zap the unused "marker" files, i.e. the ".wh..*" stuff, etc. that gets left behind when temporary files (like "vi" scratch files) get removed... You don't want to back up the marker files as part of the dump... they're artifacts of the unionfs file abstraction... -Philip ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED]
