Menu
▾
▴
Re: [Astlinux-devel] unionfs and Linux 3.16
|
From: Lonnie A. <li...@lo...> - 2017-08-25 17:54:53
|
Devs, (update) > -- > Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' > -- I still recommend the above rule. Though looking at the unionfs kernel documentation -=-=-=-= Documentation/filesystems/unionfs/usage.txt -=-=-=-= CACHE CONSISTENCY ================= If you modify any file on any of the lower branches directly, while there is a Unionfs 2.x mounted above any of those branches, you should tell Unionfs to purge its caches and re-get the objects. To do that, you have to increment the generation number of the superblock using the following command: # mount -t unionfs -o remount,incgen none MOUNTPOINT -=-=-=-= Indeed, if I remove a directory in the path '/oldroot/mnt/asturw/...' and *immediately* follow it with the command ... -- mount -t unionfs -o remount,incgen none / -- it seems to work (*much* better than not issuing the 'remount,incgen'), but I'm not convinced it is *perfect*. BTW as before, directly removing a file in '/oldroot/mnt/asturw/...' does not require the 'remount,incgen' and continues to work fine, as it has in the past. unionfs automatically handles the lower file removal case. So, for development purposes only, I mention this 'remount,incgen' workaround for directly removing a directory in the lower filesystem while unionfs is mounted. Best to also kernel-reboot or reboot afterwords. BTW, in Linux kernels 3.18 and beyond the unionfs alternative is overlayfs, but overlayfs forbids any lower direct file manipulation while mounted ... -=-=-=-= Documentation/filesystems/overlayfs.txt -=-=-=-= Changes to underlying filesystems --------------------------------- Offline changes, when the overlay is not mounted, are allowed to either the upper or the lower trees. Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock. -=-=-=-= Lonnie On Jun 1, 2017, at 8:30 PM, Lonnie Abelbeck <li...@lo...> wrote: > > On Jun 1, 2017, at 7:21 PM, David Kerr <Da...@Ke...> wrote: > >> Okay, so... occasionally I replace a file in e.g. /usr/sbin while testing some change I may have made. When that change is eventually incorporated into the build tree I am in the habit of going into /oldroot/mnt/asturw/usr and then rm -rf sbin. >> >> I think you are saying that this is bad? Right? > > I used to do that as well, don't remove any directories, though removing a file is fine. I found this out by cleaning-up after editing the traffic shaper plugin for testing. > -- > Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' > -- > > >> So instead I should go into /oldroot/mnt/asturw/usr/sbin and rm the file, and just leave the sbin directory alone? > > Yes, to help, the new "show-union" will not show you the empty directories anymore. Simply ignore the ASTURW empty directories. > > Some day we may consider automatically cleaning up these empty directories if we ever thought they could be a problem, but a non-issue today. That would have to be done in the initrd. > > >> What are the consequences of erasing the directory? And if I do erase a directory will a reboot make things okay again? > > It seems any open file in the path will get flushed from memory, typically the AIF plugin helper scripts will be effected if '/oldroot/mnt/asturw/usr/...' and as such you won't get a clean shutdown, you will need to power cycle the box. > > We can hope the unionfs folks will generate a new set of patches, but I would expect we just need to live with this. > > As I recall, many years ago in the Linux 2.6 days. several versions of unionfs ago, this same problem existed. > > Lonnie > > > >> Thanks >> David >> >> On Thu, Jun 1, 2017 at 9:55 AM, Lonnie Abelbeck <li...@lo...> wrote: >> Hi Devs, >> >> First, it has been 10 days since we bumped the kernel to 3.16.43, and things appear to be running solid at this point, much thanks for all the assistance in getting this major task accomplished. >> >> Though I ran across a glitch, with unionfs, basically you no longer can remove a *directory* in the path '/oldroot/mnt/asturw/...' as unionfs with kernel 3.16 has an issue with that. Such a deletion now also effects open files in the same path, in memory. >> >> Removing a *file* in the '/oldroot/mnt/asturw/...' path appears to be OK, which is important, since that is the only way to "undo" an edit of a file on '/oldroot/mnt/asturo/...' >> >> I sent an email to Erez Zadok at Stony Brook University as well as the unionfs mailing list, where I go into more detail. >> >> [Unionfs] unionfs with Linux 3.16 >> http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2017-May/006196.html >> >> I looked over our scripts and we only needed a few changes to implement the new rule: >> -- >> Rule: Never remove a directory in the path '/oldroot/mnt/asturw/...' >> -- >> (Revision: 8361) >> >> The 'show-union' command now only shows files, so as not to encourage directory removal, except 'show-union all' shows directories as well. >> >> Any stale directories on ASTURW should not happen for normal users in production, but during development it can be handy to edit ASTURO files, so if you wanted to remove these stale directories (leaving them be is fine) you need to reboot to RUNNIX and mount /dev/sda2 as -t ext2. >> >> Lonnie >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
