From: Mark Mielke <mark@mark.mielke.cc>
To: Oliver Xymoron <oxymoron@waste.org>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Paul Allen <allenp@nwlink.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Ext2 zeros inode in directory entry when deleting files.
Date: Sun, 17 Mar 2002 18:53:56 -0500 [thread overview]
Message-ID: <20020317185356.C16140@mark.mielke.cc> (raw)
In-Reply-To: <20020317131702.A16140@mark.mielke.cc> <Pine.LNX.4.44.0203171516540.21552-100000@waste.org>
In-Reply-To: <Pine.LNX.4.44.0203171516540.21552-100000@waste.org>; from oxymoron@waste.org on Sun, Mar 17, 2002 at 03:20:19PM -0600
On Sun, Mar 17, 2002 at 03:20:19PM -0600, Oliver Xymoron wrote:
> On Sun, 17 Mar 2002, Mark Mielke wrote:
> > Out of curiosity... how would you mark the first entry in a directory
> > as 'deleted' under your suggestion?
> As it happens, the first entry tends to be '.'.
If this was a guarantee, I would assume that the initial two entries
could be optimized as two inodes.
> > Also, I'm not certain, but I suspect that the reclen vs namelen
> > difference allows the ext2(/3) format to be extended while minimizing
> > breakage to existing code. One day another field might be added to the
> > inode and any assumptions regarding the size of a record length would
> > limit such extensions. (One such field is currently the 'file type',
> > although, the file type does not actually use up any additional bytes)
> Doesn't matter, reclen still makes it a linked list, and we'd still skip
> over 'dead' entries, regardless of content.
If the extra bytes (reclen - namelen) *were* extra bits of file system
information, there would be no safe way of ensuring that the allocation
of a new directory entry didn't 'accidentally' overwrite these bytes.
Exactly how big should you assume reclen *really* is, if reclen
sometimes means the length of the record, and other times means a next
pointer offset?
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
next prev parent reply other threads:[~2002-03-17 23:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-16 8:24 Ext2 zeros inode in directory entry when deleting files Paul Allen
2002-03-16 9:02 ` Alexander Viro
2002-03-17 7:25 ` tytso
2002-03-17 17:21 ` Oliver Xymoron
2002-03-17 18:17 ` Mark Mielke
2002-03-17 21:20 ` Oliver Xymoron
2002-03-17 23:53 ` Mark Mielke [this message]
2002-03-19 0:50 ` Paul Allen
2002-03-19 1:34 ` Andreas Dilger
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=20020317185356.C16140@mark.mielke.cc \
--to=mark@mark.mielke.cc \
--cc=allenp@nwlink.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oxymoron@waste.org \
--cc=tytso@mit.edu \
/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