a (documented) way to get the Ext2+ filesystem size?

a (documented) way to get the Ext2+ filesystem size?

[Ivan Shmakov]

	How do I get the Ext2+ filesystem size (in blocks)?

	Currently, I do it like:

static uint_fast64_t
e2fs_size (ext2_filsys e2)
{
  uint_fast32_t hi
    = (uint_fast32_t)e2->super->s_blocks_count_hi;
  uint_fast32_t lo
    = (uint_fast32_t)e2->super->s_blocks_count;

  /* . */
  return (((uint64_t)hi << 32) | lo);
}

	However, it seems that there's no documentation for both the
	ext2_filsys and struct ext2_super_block structure types, and
	their respective member fields.

	Am I safe with the code above?

-- 
FSF associate member #7257

Re: a (documented) way to get the Ext2+ filesystem size?

[Jan Kara]

On Tue 16-08-11 18:37:23, Ivan Shmakov wrote:
> 	How do I get the Ext2+ filesystem size (in blocks)?
> 
> 	Currently, I do it like:
> 
> static uint_fast64_t
> e2fs_size (ext2_filsys e2)
> {
>   uint_fast32_t hi
>     = (uint_fast32_t)e2->super->s_blocks_count_hi;
>   uint_fast32_t lo
>     = (uint_fast32_t)e2->super->s_blocks_count;
> 
>   /* . */
>   return (((uint64_t)hi << 32) | lo);
> }
> 
> 	However, it seems that there's no documentation for both the
> 	ext2_filsys and struct ext2_super_block structure types, and
> 	their respective member fields.
> 
> 	Am I safe with the code above?
  Yes, this is correct.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: a (documented) way to get the Ext2+ filesystem size?

[Ted Ts'o]

On Tue, Aug 16, 2011 at 06:37:23PM +0700, Ivan Shmakov wrote:
> 	How do I get the Ext2+ filesystem size (in blocks)?

I assume you need the exact numbers, so you can't use statfs(2)?  What
are you using it for?

  	     	      	    	     - Ted

Re: a (documented) way to get the Ext2+ filesystem size?

[Ivan Shmakov]

>>>>> Ted Ts'o <tytso@mit.edu> writes:
>>>>> On Tue, Aug 16, 2011 at 06:37:23PM +0700, Ivan Shmakov wrote:

 >> How do I get the Ext2+ filesystem size (in blocks)?

 > I assume you need the exact numbers, so you can't use statfs(2)?
 > What are you using it for?

	The intent is to process a filesystem image, not a mounted
	filesystem.  It's my understanding that I cannot use neither
	statfs(2) nor POSIX' statvfs(2) in this case.

	The code I've posted earlier is used in my e2dis [1–3] project.

[1] http://article.gmane.org/gmane.linux.debian.devel.general/164488
[2] http://article.gmane.org/gmane.comp.file-systems.ext4/27269
[3] https://gitorious.org/e2dis/

-- 
FSF associate member #7257	Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a (documented) way to get the Ext2+ filesystem size?

[Ted Ts'o]

On Thu, Aug 18, 2011 at 01:50:48AM +0700, Ivan Shmakov wrote:
> >>>>> Ted Ts'o <tytso@mit.edu> writes:
> >>>>> On Tue, Aug 16, 2011 at 06:37:23PM +0700, Ivan Shmakov wrote:
> 
>  >> How do I get the Ext2+ filesystem size (in blocks)?
> 
>  > I assume you need the exact numbers, so you can't use statfs(2)?
>  > What are you using it for?
> 
> 	The intent is to process a filesystem image, not a mounted
> 	filesystem.  It's my understanding that I cannot use neither
> 	statfs(2) nor POSIX' statvfs(2) in this case.
> 
> 	The code I've posted earlier is used in my e2dis [1–3] project.

For this, I'd suggest that you use the ext2fs library.  That will take
care of byte swapping, etc.  It also means that you don't have to
worry about parsing the extent trees.  If you had used the ext2fs
library before ext4 had shipped, you wouldn't have had to make any
changes to support extents, since the ext2fs library wraps and
provides abstract interfaces for most of what you would need for e2dis
project.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a (documented) way to get the Ext2+ filesystem size?

[Steven Liu]

Hi, Ivan,


      Do you want use mkfs.ext2 to make a small ext2 image file
     and write the image to mmc or some devices?

     when you write it to block device, the tool can modify the sb info
     about the file system size?

    for example:

           You must cost  60s to write a 64MB ext2 image
           You want to make a 8MB ext2 image
           So you can cost little time to write image to block device
           and use 64MB partition space?


    Is this?




Best Regards?


2011/8/18 Ted Ts'o <tytso@mit.edu>:
> On Thu, Aug 18, 2011 at 01:50:48AM +0700, Ivan Shmakov wrote:
>> >>>>> Ted Ts'o <tytso@mit.edu> writes:
>> >>>>> On Tue, Aug 16, 2011 at 06:37:23PM +0700, Ivan Shmakov wrote:
>>
>>  >> How do I get the Ext2+ filesystem size (in blocks)?
>>
>>  > I assume you need the exact numbers, so you can't use statfs(2)?
>>  > What are you using it for?
>>
>>       The intent is to process a filesystem image, not a mounted
>>       filesystem.  It's my understanding that I cannot use neither
>>       statfs(2) nor POSIX' statvfs(2) in this case.
>>
>>       The code I've posted earlier is used in my e2dis [1–3] project.
>
> For this, I'd suggest that you use the ext2fs library.  That will take
> care of byte swapping, etc.  It also means that you don't have to
> worry about parsing the extent trees.  If you had used the ext2fs
> library before ext4 had shipped, you wouldn't have had to make any
> changes to support extents, since the ext2fs library wraps and
> provides abstract interfaces for most of what you would need for e2dis
> project.
>
> Regards,
>
>                                        - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

e2dis example usage pattern

[Ivan Shmakov]

>>>>> Steven Liu <lingjiujianke@gmail.com> writes:
>>>>> 2011/8/18 Ted Ts'o <tytso@mit.edu>:
>>>>> On Thu, Aug 18, 2011 at 01:50:48AM +0700, Ivan Shmakov wrote:

	(Crossposting to debian-devel@, as there may be interested
	parties there as well.)

[…]

 >>> The code I've posted earlier is used in my e2dis [1–3] project.

 >>> [1] http://article.gmane.org/gmane.linux.debian.devel.general/164488
 >>> [2] http://article.gmane.org/gmane.comp.file-systems.ext4/27269
 >>> [3] https://gitorious.org/e2dis/

[…]

 > Do you want use mkfs.ext2 to make a small ext2 image file and write
 > the image to mmc or some devices?

 > when you write it to block device, the tool can modify the sb info
 > about the file system size?

[…]

 > Is this?

	For that purpose, I'd probably use resize2fs(8).

	However, my intent is different.  Namely, my aim is to provide a
	Jigdo-like [4] tool for Ext2+ FS, to be used to reduce the
	burden to store and distribute Ext2+ FS images over the
	Internet.

	The example use for the tool would be as follows:

	• one prepares a Debian GNU/Linux “Live” image (to be written to
	  a removable USB Flash medium, or used in “virtualized”
	  environments);

	• the typical size of such an image is 1 GiB; it's cumbersome to
	  host, especially if one considers hosting an image for each
	  architecture (say, IA-32, AMD64, and ARM), suite (say, Debian
	  stable, testing and unstable) and variant (say, Gnome, KDE,
	  LXDE; thus totalling to 27 images);

	• however, most of the files on such images would bytewise match
	  those in the .deb packages, which are universally available;

	• therefore, one prepares a /mapping/ of the Ext2+ FS image
	  locations to the files contained within the .deb packages;

	• this mapping, along with a compressed data of the parts of the
	  image for which no corresponding file is known (free blocks,
	  FS service areas, files generated at the installation time,
	  etc.) is hosted on an HTTP server for distribution;

	• anyone interested in such an image downloads the mapping, the
	  compressed “dry remainder” of the image, and starts the image
	  download and reassembly software (yet to be developed);

	• this software downloads the necessary .deb files off the
	  nearby Debian mirror, extracts the files therein, and uses
	  them to “fill the gaps” within the dry remainder;

	• this results in an exact (bytewise) copy of the image
	  processed earlier with e2dis.

	In addition to Jigdo, the operation of the suite is not unlike
	that of the software supporting Metalink [5–7].

[4] http://atterer.org/jigdo/
[5] http://en.wikipedia.org/wiki/Metalink
[6] http://www.metalinker.org/
[7] http://www.rfc-editor.org/rfc/rfc5854.txt

-- 
FSF associate member #7257	Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a (documented) way to get the Ext2+ filesystem size?

[Ivan Shmakov]

>>>>> Ted Ts'o <tytso@mit.edu> writes:
>>>>> On Thu, Aug 18, 2011 at 01:50:48AM +0700, Ivan Shmakov wrote:

[…]

 >> The intent is to process a filesystem image, not a mounted
 >> filesystem.  It's my understanding that I cannot use neither
 >> statfs(2) nor POSIX' statvfs(2) in this case.

 >> The code I've posted earlier is used in my e2dis [1–3] project.

 > For this, I'd suggest that you use the ext2fs library.  That will
 > take care of byte swapping, etc.  It also means that you don't have
 > to worry about parsing the extent trees.  If you had used the ext2fs
 > library before ext4 had shipped, you wouldn't have had to make any
 > changes to support extents, since the ext2fs library wraps and
 > provides abstract interfaces for most of what you would need for
 > e2dis project.

	I don't seem to understand.  I've scanned through the
	(libext2fs.info) Function Index section (as per the Debian's
	e2fslibs-dev package, 1.41.12-2), and I see no mention of a
	function that I can use for that.

	Thus, I've ended up writing my own one, which takes an
	ext2_filsys handle, and references, via its ‘super’ member, the
	‘s_blocks_count’ and ‘s_blocks_count_hi’ members of the
	superblock structure.

	However, I was concerned that I don't seem to find the
	documentation for these structures' contents anywhere.  (Sans
	the source, of course), and wondered, if the interface I use is
	at least stable?

	TIA.

-- 
FSF associate member #7257	Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a (documented) way to get the Ext2+ filesystem size?

[Ted Ts'o]

On Thu, Aug 18, 2011 at 10:49:38AM +0700, Ivan Shmakov wrote:
>  > For this, I'd suggest that you use the ext2fs library.  That will
>  > take care of byte swapping, etc.  It also means that you don't have
>  > to worry about parsing the extent trees.  If you had used the ext2fs
>  > library before ext4 had shipped, you wouldn't have had to make any
>  > changes to support extents, since the ext2fs library wraps and
>  > provides abstract interfaces for most of what you would need for
>  > e2dis project.
> 
> 	I don't seem to understand.  I've scanned through the
> 	(libext2fs.info) Function Index section (as per the Debian's
> 	e2fslibs-dev package, 1.41.12-2), and I see no mention of a
> 	function that I can use for that.

Sorry, the documentation is not necessarily complete; my apologies.

> 	Thus, I've ended up writing my own one, which takes an
> 	ext2_filsys handle, and references, via its ‘super’ member, the
> 	‘s_blocks_count’ and ‘s_blocks_count_hi’ members of the
> 	superblock structure.

The function to do this is in the 1.42 dev branch which is in Debian
unstable, and it's called ext2fs_block_count().

> 	However, I was concerned that I don't seem to find the
> 	documentation for these structures' contents anywhere.  (Sans
> 	the source, of course), and wondered, if the interface I use is
> 	at least stable?

I make a very strong effort to ensure that interfaces which are
exposed via the shared library are stable.  If you're not sure, please
feel free to ask on the ext4 list.

Regards,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a (documented) way to get the Ext2+ filesystem size?

[Ivan Shmakov]

>>>>> Ted Ts'o <tytso@mit.edu> writes:
>>>>> On Thu, Aug 18, 2011 at 10:49:38AM +0700, Ivan Shmakov wrote:

[…]

 >> I don't seem to understand.  I've scanned through the
 >> (libext2fs.info) Function Index section (as per the Debian's
 >> e2fslibs-dev package, 1.41.12-2), and I see no mention of a function
 >> that I can use for that.

 > Sorry, the documentation is not necessarily complete; my apologies.

	Perhaps I could take a look at that later.

 >> Thus, I've ended up writing my own one, which takes an ext2_filsys
 >> handle, and references, via its ‘super’ member, the ‘s_blocks_count’
 >> and ‘s_blocks_count_hi’ members of the superblock structure.

 > The function to do this is in the 1.42 dev branch which is in Debian
 > unstable, and it's called ext2fs_block_count().

	ACK.  Thanks!

	As I don't plan to introduce a dependency on anything above
	Debian stable, I'll probably add a configure check for that
	function, and if fails, will use either my own code, or the
	copied from the newer e2fsprogs sources.

 >> However, I was concerned that I don't seem to find the documentation
 >> for these structures' contents anywhere.  (Sans the source, of
 >> course), and wondered, if the interface I use is at least stable?

 > I make a very strong effort to ensure that interfaces which are
 > exposed via the shared library are stable.  If you're not sure,
 > please feel free to ask on the ext4 list.

	ACK.  Thanks.

-- 
FSF associate member #7257	Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html