On Thu, 21 July 2005 00:25:17 -0700, Chris Wedgwood wrote:
> On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
>
> > In both cases, what used to be a proper offset in one fd can be
> > complete bogus for another one.
>
> Exactly.
>
> Knowing the position within a directory is of
On Wed, 20 July 2005 20:48:17 +0200, Jan Blunck wrote:
>
> I don't want to tell where these are in general, I need an easy way to
> seek to the m'th directory + offset position without reading every
> single dirent. With i_sizes != 0 it is straight forward to use "the sum
> of the m
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
> In both cases, what used to be a proper offset in one fd can be
> complete bogus for another one.
Exactly.
Knowing the position within a directory is of questionable value and
trying to implement any reliable semantics for lseek is
On Wed, 20 July 2005 11:11:01 -0700, Chris Wedgwood wrote:
> On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
>
> > To my understanding, you can lseek to any "proper" offset inside a
> > directory. Proper means that the offset marks the beginning of a
> > new dirent (or end of file)
On Wed, 20 July 2005 11:11:01 -0700, Chris Wedgwood wrote:
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
To my understanding, you can lseek to any proper offset inside a
directory. Proper means that the offset marks the beginning of a
new dirent (or end of file) in the
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
In both cases, what used to be a proper offset in one fd can be
complete bogus for another one.
Exactly.
Knowing the position within a directory is of questionable value and
trying to implement any reliable semantics for lseek is
On Wed, 20 July 2005 20:48:17 +0200, Jan Blunck wrote:
I don't want to tell where these are in general, I need an easy way to
seek to the m'th directory + offset position without reading every
single dirent. With i_sizes != 0 it is straight forward to use the sum
of the m directory's
On Thu, 21 July 2005 00:25:17 -0700, Chris Wedgwood wrote:
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
In both cases, what used to be a proper offset in one fd can be
complete bogus for another one.
Exactly.
Knowing the position within a directory is of questionable
Jan Blunck wrote:
I don't want to tell where these are in general, I need an easy way to
seek to the m'th directory + offset position without reading every
single dirent. With i_sizes != 0 it is straight forward to use "the
sum of the m directory's i_sizes + offset" as the f_pos to seek to.
Jan Blunck wrote:
Also, how is lseek + readdir supposed to work in general?
This is how libc is reading directories (at least on arch s390x):
getdents() != 0
lseek() to d_off of last dirent
getdents() != 0
lseek() to d_off of last dirent
getdents() == 0
return
Therefore I really need
Chris Wedgwood wrote:
To my understanding, you can lseek to any "proper" offset inside a
directory. Proper means that the offset marks the beginning of a
new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where these are in general.
I don't want
Chris Wedgwood wrote:
Hos does that work if offset >= m?
Eerrh, did you actually read my patch? The i_size of a directory is
increased by SIMPLE_BOGO_DIRENT_SIZE for every entry in the directory.
>>So you can seek to m*+ to access an offset into
>>> >something at depth m?
>>> >
>>
>> Yes.
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
> To my understanding, you can lseek to any "proper" offset inside a
> directory. Proper means that the offset marks the beginning of a
> new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where
On Tue, 19 July 2005 12:16:48 -0700, Chris Wedgwood wrote:
>
> Also, how is lseek + readdir supposed to work in general?
To my understanding, you can lseek to any "proper" offset inside a
directory. Proper means that the offset marks the beginning of a new
dirent (or end of file) in the
On Tue, 19 July 2005 12:16:48 -0700, Chris Wedgwood wrote:
Also, how is lseek + readdir supposed to work in general?
To my understanding, you can lseek to any proper offset inside a
directory. Proper means that the offset marks the beginning of a new
dirent (or end of file) in the
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
To my understanding, you can lseek to any proper offset inside a
directory. Proper means that the offset marks the beginning of a
new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where
Chris Wedgwood wrote:
Hos does that work if offset = m?
Eerrh, did you actually read my patch? The i_size of a directory is
increased by SIMPLE_BOGO_DIRENT_SIZE for every entry in the directory.
So you can seek to m*stack-depth+offset to access an offset into
something at depth m?
Chris Wedgwood wrote:
To my understanding, you can lseek to any proper offset inside a
directory. Proper means that the offset marks the beginning of a
new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where these are in general.
I don't want
Jan Blunck wrote:
Also, how is lseek + readdir supposed to work in general?
This is how libc is reading directories (at least on arch s390x):
getdents() != 0
lseek() to d_off of last dirent
getdents() != 0
lseek() to d_off of last dirent
getdents() == 0
return
Therefore I really need
Jan Blunck wrote:
I don't want to tell where these are in general, I need an easy way to
seek to the m'th directory + offset position without reading every
single dirent. With i_sizes != 0 it is straight forward to use the
sum of the m directory's i_sizes + offset as the f_pos to seek to.
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote:
> >So you can seek to m*+ to access an offset into
> >something at depth m?
> >
>
> Yes.
Hos does that work if offset >= m?
> I disagree. Where is the information value of i_size if we always
> could return 0?
Directories clearly
Chris Wedgwood wrote:
So the size you want to reflect is n* i take it? Where
in this case n is 20?
So you can seek to m*+ to access an offset into
something at depth m?
Yes.
The i_size of a directory isn't covered by the POSIX standard. IMO,
it should be possible to seek in the range of
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote:
> Since these "arranged" values are also used as the offsets in the
> return dirent IMO it is quite clean.
So the size you want to reflect is n* i take it? Where
in this case n is 20?
So you can seek to m*+ to access an offset into
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: [X]
f_pos=0
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck 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.
> Therefore I need values of
Linus Torvalds wrote:
I really think you should update the "simple_xxx()" functions instead, and
thus make this happen for _any_ filesystem that uses the simple fs helper
functions.
Ok, I revised the patch. This is just the first step with changes to
libfs and ramfs.
To move the
Chris Wedgwood wrote:
Why bother at all?
I don't see why zero sizes are a problem. We've had them for year
without complaints.
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.
Bodo Eggert wrote:
Jan Blunck <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> Does it really matter?
>
Yes! At least for me and my union mounts implementation.
Is there a reason for not using size == link-count (or even static)?
Yes, the link count is only increased for
Bodo Eggert wrote:
Jan Blunck [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Does it really matter?
Yes! At least for me and my union mounts implementation.
Is there a reason for not using size == link-count (or even static)?
Yes, the link count is only increased for subdirectories
Chris Wedgwood wrote:
Why bother at all?
I don't see why zero sizes are a problem. We've had them for year
without complaints.
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.
Linus Torvalds wrote:
I really think you should update the simple_xxx() functions instead, and
thus make this happen for _any_ filesystem that uses the simple fs helper
functions.
Ok, I revised the patch. This is just the first step with changes to
libfs and ramfs.
To move the
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck 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.
Therefore I need values of dirent-d_off
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: [X]
f_pos=0
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote:
Since these arranged values are also used as the offsets in the
return dirent IMO it is quite clean.
So the size you want to reflect is n*stack-depth i take it? Where
in this case n is 20?
So you can seek to m*stack-depth+offset to
Chris Wedgwood wrote:
So the size you want to reflect is n*stack-depth i take it? Where
in this case n is 20?
So you can seek to m*stack-depth+offset to access an offset into
something at depth m?
Yes.
The i_size of a directory isn't covered by the POSIX standard. IMO,
it should be
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote:
So you can seek to m*stack-depth+offset to access an offset into
something at depth m?
Yes.
Hos does that work if offset = m?
I disagree. Where is the information value of i_size if we always
could return 0?
Directories
Jan Blunck <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Does it really matter?
> >
>
> Yes! At least for me and my union mounts implementation.
Is there a reason for not using size == link-count (or even static)?
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
Jan Blunck [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Does it really matter?
Yes! At least for me and my union mounts implementation.
Is there a reason for not using size == link-count (or even static)?
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote:
> I really think you should update the "simple_xxx()" functions
> instead, and thus make this happen for _any_ filesystem that uses
> the simple fs helper functions.
Why bother at all?
I don't see why zero sizes are a problem.
On Fri, 15 Jul 2005, Jan Blunck wrote:
>
> This patch adds bogo dirent sizes for ramfs like already available for
> tmpfs.
I really think you should update the "simple_xxx()" functions instead, and
thus make this happen for _any_ filesystem that uses the simple fs helper
functions.
Andrew Morton wrote:
>
> Does it really matter?
>
Yes! At least for me and my union mounts implementation.
>
> I wonder if these should be in libfs - sysfs has the same problem, for
> example and someone might want to come along and fix that up too.
Ok, I will check that next week. But AFAIK,
Andrew Morton wrote:
Does it really matter?
Yes! At least for me and my union mounts implementation.
I wonder if these should be in libfs - sysfs has the same problem, for
example and someone might want to come along and fix that up too.
Ok, I will check that next week. But AFAIK, sysfs
On Fri, 15 Jul 2005, Jan Blunck wrote:
This patch adds bogo dirent sizes for ramfs like already available for
tmpfs.
I really think you should update the simple_xxx() functions instead, and
thus make this happen for _any_ filesystem that uses the simple fs helper
functions.
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote:
I really think you should update the simple_xxx() functions
instead, and thus make this happen for _any_ filesystem that uses
the simple fs helper functions.
Why bother at all?
I don't see why zero sizes are a problem. We've
Jan Blunck <[EMAIL PROTECTED]> wrote:
>
> This patch adds bogo dirent sizes for ramfs like already available for
> tmpfs.
>
> Although i_size of directories isn't covered by the POSIX standard it is
> a bad idea to always set it to zero. Therefore pretend a bogo dirent
> size for directory
This patch adds bogo dirent sizes for ramfs like already available for
tmpfs.
Although i_size of directories isn't covered by the POSIX standard it is
a bad idea to always set it to zero. Therefore pretend a bogo dirent
size for directory i_sizes.
Jan
Signed-off-by: Jan Blunck <[EMAIL
This patch adds bogo dirent sizes for ramfs like already available for
tmpfs.
Although i_size of directories isn't covered by the POSIX standard it is
a bad idea to always set it to zero. Therefore pretend a bogo dirent
size for directory i_sizes.
Jan
Signed-off-by: Jan Blunck [EMAIL
Jan Blunck [EMAIL PROTECTED] wrote:
This patch adds bogo dirent sizes for ramfs like already available for
tmpfs.
Although i_size of directories isn't covered by the POSIX standard it is
a bad idea to always set it to zero. Therefore pretend a bogo dirent
size for directory i_sizes.
48 matches
Mail list logo
