From: Nicholas Miell <nmiell@comcast.net>
To: David Chinner <dgc@sgi.com>
Cc: Josef Sipek <jsipek@fsl.cs.sunysb.edu>,
Nikolai Joukov <kolya@cs.sunysb.edu>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4
Date: Wed, 06 Dec 2006 19:14:58 -0800 [thread overview]
Message-ID: <1165461298.2817.10.camel@entropy> (raw)
In-Reply-To: <20061207024944.GM44411608@melbourne.sgi.com>
On Thu, 2006-12-07 at 13:49 +1100, David Chinner wrote:
> On Wed, Dec 06, 2006 at 09:35:30PM -0500, Josef Sipek wrote:
> > On Thu, Dec 07, 2006 at 12:44:27PM +1100, David Chinner wrote:
> > > Maybe we should be using EAs for this sort of thing instead of flags
> > > on the inode? If we keep adding inode flags for generic features
> > > then we are going to force more than just XFS into inode format
> > > changes eventually....
> >
> > Aren't EAs slow? Maybe not on XFS but on other filesystems...
>
> Only when they don't fit in the inode itself and extra
> disk seeks are needed to retrieve them.
>
> Cheers,
>
> Dave.
Also keep in mind that the EA doesn't actually have to have a physical
representation on disk (or, rather, it does, but it doesn't need to be
the same representation used by EAs in the user namespace).
This means that if one of those slow EA filesystems still has room for
flags in the inode, it can synthesize the EA on demand.
This is even preferable to ioctls for the interface to new filesystem
metadata -- if a backup or archive program knows how to store EAs, it
will be able to save and restore any new exotic metadata without any
extra effort.
--
Nicholas Miell <nmiell@comcast.net>
next prev parent reply other threads:[~2006-12-07 3:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-04 18:33 [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4 Nikolai Joukov
2006-12-04 23:50 ` David Chinner
2006-12-05 16:41 ` Nikolai Joukov
2006-12-06 9:11 ` David Chinner
2006-12-06 22:16 ` Nathan Scott
2006-12-07 0:56 ` Josef Sipek
2006-12-07 1:44 ` David Chinner
2006-12-07 2:35 ` Josef Sipek
2006-12-07 2:49 ` David Chinner
2006-12-07 3:14 ` Nicholas Miell [this message]
2006-12-07 5:35 ` Josef Sipek
2006-12-07 5:45 ` Nathan Scott
2006-12-09 1:44 ` Nikolai Joukov
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=1165461298.2817.10.camel@entropy \
--to=nmiell@comcast.net \
--cc=dgc@sgi.com \
--cc=jsipek@fsl.cs.sunysb.edu \
--cc=kolya@cs.sunysb.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@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).