Re: FIGETBSZ and FIBMAP for directorys

[Nikita Danilov]

Sebastian Claъen writes:
 > Hi list...
 > 
 > I'm using this little program to find out which blocks are use by a
 > particular file:
 > int main(int argc, char **argv) {
 >         int             fd,
 >                         i,
 >                         block,
 >                         blocksize,
 >                         bcount;
 >         struct stat     st;
 > 
 >         assert(argv[1] != NULL);
 >         assert(fd=open(argv[1], O_RDONLY));
 >         assert(ioctl(fd, FIGETBSZ, &blocksize) == 0);
 >         assert(!fstat(fd, &st));

Now, if somebody compiles this with NDEBUG? It is bad practice to put
code with side-effects into assertions.

[...]

 > 
 > This works fine for regular files, but not for directorys. Both ioctl's,
 > FIGETBSZ and FIBMAP, are implemented for regular files only. 

FIBMAP is obsolete API, I believe. For certain file systems it doesn't
make sense to ask "in what block, i-th logical block of given file
lives?" for directory files, because directories do not have linear
structure, e.g., are implemented as B-trees. Not incidentally these are
the same file systems that have trouble supporting optional
seekdir/telldir API.

Moreover, for some file systems this question doesn't make a lot of
sense even for regular files, e.g., because small files can be stored in
the same block, or some blocks might be in the "unallocated state", or
file system does behind-the-back relocation to improve disk layout, etc.

Nor does it make sense to ask such questions when files are stripped
over multiple devices, or served over network, or backed up by memory...

Basically, FIBMAP is a hack.

 > 
 > Is there a patch to make this FIGETBSZ and FIBMAP work on directorys
 > too?
 > Or alternativly, is there a way to find out which blocks are used by a
 > directory?
 > 
 > Thanks for answers in advance
 >   Sebastian.
 > 
 > 

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/