xfs
[Top] [All Lists]

Re: Beta contents/date

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Beta contents/date
From: Steve Lord <lord@xxxxxxx>
Date: Thu, 13 Apr 2000 08:59:22 -0500
Cc: lord@xxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx> of "Thu, 13 Apr 2000 09:17:48 +1000." <200004122317.JAA64410@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
> 
> Steve Lord <lord@xxxxxxx> writes:
> 
>  =>  o V1 directories will probably break all over the place when used on
>  =>    Linux - this becomes an issue if we can mount Irix volumes on Linux
>  =>    as most of these will still be V1.
> 
> I'm in the middle of the architecture work for V1 directories. Could
> you fill me in on what issues there are with then on Linux?
> 
> Ta...
> -----------------------------------------------------
>  Daniel Moore                  dxm@xxxxxxx
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------

The directory offset information returned in V1 is a 64 bit value made up
of two halves. If only 32 bits are saved used by user space then there could
be issues with the glibc getdents implementation. getdents is converting from
a kernel structure to a user space structure, it uses a heuristic to determine
how much to prune the users request back so that the data returned from
the kernel will still fit in the user's buffer. This heuristic appears to
fail regularly - at which point the glibc getdents code seeks backwards in
the file. 

The seek will reset the file offset back again - and we will possibly repeat
or skip entries - an infinite loop is possible.

There may be other consequences too.

Steve



<Prev in Thread] Current Thread [Next in Thread>