I was looking at various file systems and how they return
stat.st_blocks and stat.st_size for directories and had some questions
on how a fuse filesystem is supposed to implement readdir with the
seek offset when trying to union two directories together.
Is the offset a byte offset into the DIR *dp? or is it the struct
dirent size (which is relative based on the name of the file) into the
dir pointer?
Also, if you want to be accurate when you stat a directory that's
unioned in the fuse file system how many blocks should one return?
Since each filesystem seems to return different values for size and
number of blocks for directories. I know I could just say that its not
supported with my filesystem built using fuse... but I'd like to at
least try to be accurate.
Is it accurate to assume that the size or number of blocks returned
from a stat will be used to pass a seek offset?
When does fuse use the seek offset?
These are the number of blocks and size on an empty dir.
ext3
size 4096 nblocks 8
reiserfs
size 48 nblocks 0
jfs
size 1 nblocks 0
xfs
size 6 nblocks 0
Any help to figure out how to union two directories and return correct
values would be helpful.
Thanks,
- David Brown
P.S. maybe a posix filesystem interface manual would be good?
"David Brown" <[email protected]> writes:
> I was looking at various file systems and how they return
> stat.st_blocks and stat.st_size for directories and had some questions
> on how a fuse filesystem is supposed to implement readdir with the
> seek offset when trying to union two directories together.
>
> Is the offset a byte offset into the DIR *dp? or is it the struct
> dirent size (which is relative based on the name of the file) into the
> dir pointer?
I think it is totaly your call what you store in it. Only requirement
is that you never pass 0 to the filler function.
off_t is 64bit so storing DIR* in it should be no problem. Or a
pointer to
struct UnionDIR {
DIR *dp;
struct UnionDIR *next;
}
> Also, if you want to be accurate when you stat a directory that's
> unioned in the fuse file system how many blocks should one return?
> Since each filesystem seems to return different values for size and
> number of blocks for directories. I know I could just say that its not
> supported with my filesystem built using fuse... but I'd like to at
> least try to be accurate.
You could add them up and round it to some common block size (if they
differ). But I don't think it maters and nothing uses that info.
What is more important is the link count. For example find uses the
link count to know how many subdirs a directory has. Once it found
that many it assumes there are no more dirs and saves on stat() calls.
> Is it accurate to assume that the size or number of blocks returned
> from a stat will be used to pass a seek offset?
>
> When does fuse use the seek offset?
Afaik never. The offset is only stored for the next readdir call but
never used inside fuse.
> These are the number of blocks and size on an empty dir.
> ext3
> size 4096 nblocks 8
> reiserfs
> size 48 nblocks 0
> jfs
> size 1 nblocks 0
> xfs
> size 6 nblocks 0
>
> Any help to figure out how to union two directories and return correct
> values would be helpful.
Why don't you use the existing fuse-unionfs?
> Thanks,
> - David Brown
>
> P.S. maybe a posix filesystem interface manual would be good?
MfG
Goswin
> P.S. maybe a posix filesystem interface manual would be good?
Maybe you are looking for this:
http://www.opengroup.org/onlinepubs/009695399/
Miklos
> Why don't you use the existing fuse-unionfs?
I thought about doing this but it would need to be modified somehow
and even then my users would look to me to fix issues and I don't like
trying to find hard bugs in other peoples code.
Also, there's a lot of functionality that funionfs has but I don't
need and the extra code would get in the way attempting to modify or
debug issues.
What I want is fairly specific and I've not seen anything out there to do it.
Thanks,
- David Brown
"David Brown" <[email protected]> writes:
>> Why don't you use the existing fuse-unionfs?
>
> I thought about doing this but it would need to be modified somehow
> and even then my users would look to me to fix issues and I don't like
> trying to find hard bugs in other peoples code.
>
> Also, there's a lot of functionality that funionfs has but I don't
> need and the extra code would get in the way attempting to modify or
> debug issues.
>
> What I want is fairly specific and I've not seen anything out there to do it.
>
> Thanks,
> - David Brown
You can still read their code to see how they solved problems you
have.
MfG
Goswin