mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: "David Brown" <dmlb2000@gmail.com>
Cc: fuse-devel@lists.sourceforge.net,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [fuse-devel] FS block count, size and seek offset?
Date: Mon, 18 Jun 2007 10:55:39 +0200	[thread overview]
Message-ID: <87645lr69g.fsf@informatik.uni-tuebingen.de> (raw)
In-Reply-To: <9c21eeae0706171428u5a9ff79rad2b2083d3436d7f@mail.gmail.com> (David Brown's message of "Sun, 17 Jun 2007 14:28:28 -0700")

"David Brown" <dmlb2000@gmail.com> 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

  reply	other threads:[~2007-06-18  9:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-17 21:28 David Brown
2007-06-18  8:55 ` Goswin von Brederlow [this message]
2007-06-18 14:44   ` [fuse-devel] " David Brown
2007-06-19  9:40     ` Goswin von Brederlow
2007-06-18 13:32 ` Miklos Szeredi

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=87645lr69g.fsf@informatik.uni-tuebingen.de \
    --to=brederlo@informatik.uni-tuebingen.de \
    --cc=dmlb2000@gmail.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®