From: Theodore Tso <tytso@mit.edu>
To: Girish Shilamkar <girish@clusterfs.com>
Cc: Ext4 Mailing List <linux-ext4@vger.kernel.org>,
Andreas Dilger <adilger@clusterfs.com>
Subject: Re: [Patch 9/13] Adds two extended options and config file counterparts.
Date: Tue, 24 Jul 2007 12:32:54 -0400 [thread overview]
Message-ID: <20070724163254.GE11826@thunk.org> (raw)
In-Reply-To: <1185275104.3789.74.camel@dhcp4.linsyssoft.com>
On Tue, Jul 24, 2007 at 04:35:04PM +0530, Girish Shilamkar wrote:
> This patch adds two extended options and config file counterparts.
> On the command line:
>
> -E shared=preserve|lost+found|delete
>
> Select the disposition of files containing shared blocks. "preserve"
> is the old behavior which remains the default. "lost+found" causes
> files to be unlinked after cloning so they will be reconnected to
> /lost+found in pass 3. "delete" skips cloning entirely and simply
> deletes the files.
Jim Garlick and I discussed this back in April, and I pointed out a
flaw in his patch. It doesn't correctly handle the case where the
system administrator wishes to move an inode that contains blocks
claimed by other inodes to lost+found, since it only unlinks the first
filename of the inode. The result is that the inode loses one of its
directory entries, but it doesn't get oved to lost+found.
Jim reworked the patch to solve this issue, by keeping a linked list
of all of the directory entries where a particular inode could be
found. This increases the memory used and increases the time to do
pass 1C, though. The patch you have in your patch queue is the
original version of the patch, not his updated one.
I'm still not happy with this approach, though, since it adds extra
complexity and special case handling into e2fsprogs. I had made a
counter-proposal as a better long-term approach, which Jim seemed to
agree would meet his needs:
>One of my long-term plans was to extend the fix_problem() function to
>log a detailed set of problems fixed into a file (either binary or
>XML) that could parsed by other programs as part of some kind of
>recovery process. What would get written out is the problem ID plus
>the entire problem_context structure, which has actually quite a lot
>of information. This would be enough for a lot of post-processing,
>including making it easier for people to implement policies such as
>deleted or archiving for review by the Site Security Officer any files
>which had some of their blocks cloned.
- Ted
prev parent reply other threads:[~2007-07-24 16:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-24 11:05 [Patch 9/13] Adds two extended options and config file counterparts Girish Shilamkar
2007-07-24 16:32 ` Theodore Tso [this message]
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=20070724163254.GE11826@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@clusterfs.com \
--cc=girish@clusterfs.com \
--cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).