[BusyBox] Re: lazy unmount

[Rob Landley]

On Monday 01 August 2005 13:33, Rafael Espíndola wrote:
> On 7/30/05, Rob Landley <rob at landley.net> wrote:
> > Yes, and that's what's holding up the checkin.  (The mount part was done
> > a while ago...)
>
> Where can i find it?

Well, I just broke it again (integrating mtab support in-line, it seems.  And 
umount isn't freeing the loop devices again), but give me a couple hours and 
I'll post it here.

I'm currently coming up with a test script to try all the various cases I know 
about...

> > I'm ripping out -l for freeing loop devices; it should now autodetect
> > this.
>
> Nice
>
> What do you plan to change in the unmout? If there isn't going to be a
> lock to prevent the races you describe then it seems to me that umount
> will remain quite simple. Is that the case?

The races have always been there, but they're only really triggerable by root.

Face it: mount -o loop has never really tried to be reliable if several 
processes do it at once.  Right now, with the standard mount, if you mount 
the same image file read/write on two directories the filesystem in that 
image will get corrupted.  I at least fix that one, but the penalty is 
opening a different kind of race if you try to mount the same image file in 
two places at once, which at least fails gracefully (and could be mitigated 
with retry logic) rather than potentially eating data.

But the reality is, this is a corner case nobody's ever cared much about 
before. :)

> Maybe I can help with the rewrite. The sooner it is in the svn, the
> sooner gentoo will get it and the sooner I can drop my local patch :)

Aiming at later tonight.  Meant to get it done this weekend, but didn't.

Rob