Re: [Astlinux-devel] unionfs and Linux 3.16

[Lonnie A. <li...@lo...>]

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