public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Albrecht <albrecht@rdi1.com>
To: Erez Zadok <ezk@cs.sunysb.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: unionfs, cow, and whiteout
Date: Wed, 16 Jan 2008 13:48:46 -0600	[thread overview]
Message-ID: <1200512926.12092.33.camel@thinix-laptop> (raw)
In-Reply-To: <200801161713.m0GHDRUN023917@agora.fsl.cs.sunysb.edu>


On Wed, 2008-01-16 at 12:13 -0500, Erez Zadok wrote: 
> In message <1200500833.11000.0.camel@thinix-laptop>, Paul Albrecht writes:
> > Hi,
> > 
> > I have a question about how unionfs handles file deletion when a write
> > enabled file system is union mounted over a read only file system. For
> > example, I do something like the following:
> > 
> > mount -t unionfs -o dirs=/cow=rw:/rofs=ro unionfs /mnt
> > 
> > If I create and delete a file in /mnt which is not present in /rofs it
> > persists as whiteout in the cow file system which is not what I would
> > have expected.
> 
> Paul, the alternative is to scan all branches (there could be many) to
> ensure that the file may not exist by that name anywhere else, and if so,
> try to delete all instances of it.  This was deemed too expensive and
> complex.
> 

I'm not sure we're talking about the same problem. What I do is union
mount a write enabled file system like tmpfs over a read only file
system like squashfs.

There's no way to create, modify, or delete files in a squashed file
system; they can be copied up when they're modified; or, they can be
whited out when they're deleted.

Whenever a file is created in the union mount, it necessarily gets
created in tmpfs. When that file gets deleted, it gets whited out which
doesn't make sense because it doesn't exist in the other layer.

This is a problem because over time as files are created, modified, and
deleted whiteout cruft accumulates in the cow layer of the union mount.

Fixing the problem doesn't seem that complex and shouldn't require
searching all the layers of the union mount.

If the union file system simply took note of whether a file was created
in the cow layer because it's new or because it's been modified and
copied up from the read only file system, then it would simply delete
the file in the former case and and use whiteout in the latter.

> Another possible problem is that if you choose to insert a new branch in the
> middle, and you didn't have the whiteout, you may re-expose the file name
> unintentionally.
> 

I don't see how the a "deleted" file in a read only file system could be
re-exposed unless its whiteout in the cow layer was deleted, but that's
really not the issue.

What I'm objecting to is creating the whiteout in the cow layer when the
file didn't get there via a copy up from a read only file system. In
this case there's no worry about re-exposing the deleted file because
it's really deleted.

> You might want to take a look at our unionfs-odf version: it places
> whiteouts in a separate persistent store outside the branches, not as .wh.*
> files in individual branches.
> 
> > Why does the deleted file persist as whiteout in the /cow file system of
> > the union mount?
> > 
> > Please cc me in your response as I'm not subscribed to the lkml.
> > 
> > -- 
> > 
> > Paul Albrecht
> 
> Cheers,
> Erez.
-- 

Paul Albrecht

  reply	other threads:[~2008-01-16 19:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16 16:27 unionfs, cow, and whiteout Paul Albrecht
2008-01-16 17:13 ` Erez Zadok
2008-01-16 19:48   ` Paul Albrecht [this message]
2008-01-16 20:18     ` Erez Zadok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1200512926.12092.33.camel@thinix-laptop \
    --to=albrecht@rdi1.com \
    --cc=ezk@cs.sunysb.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox