All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Scott <nscott@aconex.com>
To: David Chinner <dgc@sgi.com>
Cc: Nikolai Joukov <kolya@cs.sunysb.edu>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	xfs@oss.sgi.com
Subject: Re: [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4
Date: Thu, 07 Dec 2006 09:16:31 +1100	[thread overview]
Message-ID: <1165443391.1281.135.camel@edge> (raw)
In-Reply-To: <20061206091100.GA33919298@melbourne.sgi.com>

On Wed, 2006-12-06 at 20:11 +1100, David Chinner wrote:
> ...
> If all we need to add to XFS is support for those flags, then XFS
> support would be trivial to add.
> 
> Oh, damn. I take that back. We're almost out of flag space in the on
> disk inode - these two flags would use the last 2 flag bits so this
> may require an on disk inode format change in XFS. This will be
> a little more complex than I first thought, ...

It should be OK - you can do it without an inode version revision
if you take a second 16 bits for "di_flags2" from here...

xfs_dinode_core {
	...
        __uint8_t       di_pad[8];      /* unused, zeroed space */

Its guaranteed zeroed initially (i.e. all flags unset) and the XFS
get/set flags APIs are 32 bits, so you should be OK there.

Also, it may also be possible to reclaim di_onlink at some point (maybe
now, since 16 bits would be good here) if mkfs.xfs is changed to always
create v2 inodes (dynamic conversion ATM IIRC)... not 100% sure though,
needs more code analysis.

cheers.

-- 
Nathan

  reply	other threads:[~2006-12-07  3:55 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 [this message]
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
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=1165443391.1281.135.camel@edge \
    --to=nscott@aconex.com \
    --cc=dgc@sgi.com \
    --cc=kolya@cs.sunysb.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.