From: Jan Blunck <j.blunck@tu-harburg.de>
To: Chris Wedgwood <cw@f00f.org>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Linux-Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ramfs: pretend dirent sizes
Date: Tue, 19 Jul 2005 20:22:26 +0200 [thread overview]
Message-ID: <42DD44E2.3000605@tu-harburg.de> (raw)
In-Reply-To: <20050719161623.GA11771@taniwha.stupidest.org>
Chris Wedgwood wrote:
>
>>I'm using the i_size of directories in my patches. When reading
>>from a union directory, I'm using the i_size to seek to the right
>>offset in the union stack.
>
>
> Ick. That'a a bit of a hack.
>
Don't think so:
1st dir: [XXXXXXXXXXXXXXXXXXXXX]
f_pos=0 f_pos=i_size(1st)
2nd dir: [XXXXXXXXXXX|---------]
f_pos=i_size(1st) f_pos=i_size(1st+2nd)
^
| f_pos=i_size(1st)+offset
Since these "arranged" values are also used as the offsets in the return
dirent IMO it is quite clean.
>
> Hence the value of 20 I guess --- assuming nothing will stack this
> high?
>
Nope. This value is kind of traditional: tmpfs is using it
(http://marc.theaimsgroup.com/?l=linux-kernel&m=103208296515378&w=2). I
think a better value would be 1 (one) since this is also used as the
dirent offset by dcache_readdir().
>
> I personally would prefer that to be honest or some other way that
> doesn't change i_size.
The i_size of a directory isn't covered by the POSIX standard. IMO, it
should be possible to seek in the range of i_size and a following
readdir() on the directory should succeed. But this isn't possible even
not with real file systems like ext2.
But keeping the i_size bound to zero even if the directory contains
entries does not make sense at all.
Jan
next prev parent reply other threads:[~2005-07-19 18:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-15 3:01 [PATCH] ramfs: pretend dirent sizes Jan Blunck
2005-07-15 3:11 ` Andrew Morton
2005-07-15 10:16 ` Jan Blunck
2005-07-15 18:52 ` Linus Torvalds
2005-07-16 0:39 ` Chris Wedgwood
2005-07-19 9:28 ` Jan Blunck
2005-07-19 16:16 ` Chris Wedgwood
2005-07-19 18:22 ` Jan Blunck [this message]
2005-07-19 18:32 ` Chris Wedgwood
2005-07-19 19:14 ` Jan Blunck
2005-07-19 19:16 ` Chris Wedgwood
2005-07-20 11:21 ` Jörn Engel
2005-07-20 18:11 ` Chris Wedgwood
2005-07-20 18:48 ` Jan Blunck
2005-07-20 18:52 ` Peter Staubach
2005-07-21 7:26 ` Jörn Engel
2005-07-21 7:20 ` Jörn Engel
2005-07-21 7:25 ` Chris Wedgwood
2005-07-21 7:27 ` Jörn Engel
2005-07-20 18:24 ` Jan Blunck
2005-07-20 18:50 ` Peter Staubach
2005-07-19 9:46 ` Jan Blunck
[not found] <4qoKs-6yv-13@gated-at.bofh.it>
[not found] ` <4qoU5-6CQ-3@gated-at.bofh.it>
[not found] ` <4qvsI-32Y-17@gated-at.bofh.it>
2005-07-15 13:12 ` Bodo Eggert
2005-07-19 9:13 ` Jan Blunck
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=42DD44E2.3000605@tu-harburg.de \
--to=j.blunck@tu-harburg.de \
--cc=akpm@osdl.org \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 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.