All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaya Potter <spotter@cs.columbia.edu>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] ocfs2's bmap output
Date: Fri Oct 14 00:33:34 2005	[thread overview]
Message-ID: <1129268016.8092.28.camel@localhost.localdomain> (raw)

I'm writing a stackable file system and one of it's features is that it
can combine many sparse files into a single view.  On ext2/3 I was using
bmap to give me the information needed, so for instance, if I created a
big sparse file and tacked on some information at the end on ext2/3 I'd
get something like

blade12:~# ~/a.out abc
File: abc Size: 30002 Blocks: 8 Blocksize: 4096
  0          0
  1          0
  2          0
  3          0
  4          0
  5          0
  6          0
  7     833699

where my test program basically calls bmap (or in this case as it's from
userspace, it calls the FIBMAP ioctl) on each block of the file.

however, when I run it on OCFS2, I get.

blade12:/san/lc2# ~/a.out abc
File: abc Size: 30002 Blocks: 8 Blocksize: 4096
  0    5700288
  1    5700289
  2    5700290
  3    5700291
  4    5700292
  5    5700293
  6    5700294
  7    5700295

I'm guessing this is because of its use of extents, and probably means
I've screwed myself in trying to use bmap in this way.  Is that a
correct assumption?  Is there any other interface into OCFS2 to tell if
a block is a "blank" sparse area?

thanks,

shaya

             reply	other threads:[~2005-10-14  0:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-14  0:33 Shaya Potter [this message]
2005-10-14  1:12 ` [Ocfs2-devel] ocfs2's bmap output Mark Fasheh
2005-10-14  1:18   ` Shaya Potter
2005-10-14 10:48   ` Shaya Potter
2005-10-14 16:31     ` Sunil Mushran
2005-10-14  3:51 ` Joel Becker

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=1129268016.8092.28.camel@localhost.localdomain \
    --to=spotter@cs.columbia.edu \
    --cc=ocfs2-devel@oss.oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.