off-line resizing?

off-line resizing?

[Ivan Shmakov]

	The FAQ reads:

--cut: http://www.nilfs.org/en/faq.html --
   5. Can I resize NILFS volumes ?

      Yes, you can both enlarge and shrink NILFS volumes with
      nilfs-resize command.  This feature is available on Linux 3.0 and
      later.  Resizing for unmounted file systems are not supported at
      present.

      For details, please see the man page of nilfs-resize(8).
--cut: http://www.nilfs.org/en/faq.html --

	Unfortunately, I don't plan to switch my “production” hosts to
	Linux 3 yet.  However, for the purposes I want to give NILFS a
	try I can assume that I can easily umount the volume whenever I
	need to resize it, to run whatever user-space code necessary.

	Thus, I'm curious, are there any plans to implement “off-line”
	NILFS resizing?

	TIA.

-- 
FSF associate member #7257	np. Дождь — ДДТ

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

Re: off-line resizing?

[Ryusuke Konishi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset="windows-1254", Size: 2129 bytes --]

Hi,
On Wed, 13 Jun 2012 23:06:54 +0700, Ivan Shmakov wrote:
> 	The FAQ reads:
> 
> --cut: http://www.nilfs.org/en/faq.html --
>    5. Can I resize NILFS volumes ?
> 
>       Yes, you can both enlarge and shrink NILFS volumes with
>       nilfs-resize command.  This feature is available on Linux 3.0 and
>       later.  Resizing for unmounted file systems are not supported at
>       present.
> 
>       For details, please see the man page of nilfs-resize(8).
> --cut: http://www.nilfs.org/en/faq.html --
> 
> 	Unfortunately, I don't plan to switch my “production” hosts to
> 	Linux 3 yet.  However, for the purposes I want to give NILFS a
> 	try I can assume that I can easily umount the volume whenever I
> 	need to resize it, to run whatever user-space code necessary.
> 
> 	Thus, I'm curious, are there any plans to implement “off-line”
> 	NILFS resizing?
> 
> 	TIA.

Implementing Off-line resizing is a bit tough task because it requires
a user space library to read internal meta data of the nilfs file
system and append updated blocks to it.  This is almost equivalent to
implementing kernel functions of nilfs in user land.

So, we have no concrete schedule now.

If you are using RHEL6 or its clones, however, standalone kernel
modules supporting online-resizing are available from:

  http://www.nilfs.org/en/pkg_centos.html.

For other Linux distros, the standalone kmod may be applicable with or
without customizing the source code.  it has a glue code to support
multiple kernel versions.  For reference, the source code of the
standalone kmod is available at:

  git://github.com/nilfs-dev/nilfs2-kmod-centos6.git



With regards,
Ryusuke Konishi

> -- 
> FSF associate member #7257	np. Дождь — ДДТ
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ž)_²)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

Re: off-line resizing?

[Ivan Shmakov]

>>>>> Ryusuke Konishi writes:
>>>>> On Wed, 13 Jun 2012 23:06:54 +0700, Ivan Shmakov wrote:

[…]

 >> Unfortunately, I don't plan to switch my “production” hosts to Linux
 >> 3 yet.  However, for the purposes I want to give NILFS a try I can
 >> assume that I can easily umount the volume whenever I need to resize
 >> it, to run whatever user-space code necessary.

 >> Thus, I'm curious, are there any plans to implement “off-line” NILFS
 >> resizing?

 > Implementing Off-line resizing is a bit tough task because it
 > requires a user space library to read internal meta data of the nilfs
 > file system and append updated blocks to it.  This is almost
 > equivalent to implementing kernel functions of nilfs in user land.

 > So, we have no concrete schedule now.

	ACK, thanks.

	I wonder, how complicated this task would be?  In particular, do
	I need to alter all the segments to resize filesystem, or only
	specific ones?  Also, are these internal metadata records just
	“a bunch of C structs”, or something more complex?

[…]

 > For other Linux distros, the standalone kmod may be applicable with
 > or without customizing the source code.  it has a glue code to
 > support multiple kernel versions.  For reference, the source code of
 > the standalone kmod is available at:

 > git://github.com/nilfs-dev/nilfs2-kmod-centos6.git

	ACK, thanks.

-- 
FSF associate member #7257

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

Re: off-line resizing?

[Ryusuke Konishi]

On Thu, 14 Jun 2012 11:22:17 +0700, Ivan Shmakov wrote:
> >>>>> Ryusuke Konishi writes:
> >>>>> On Wed, 13 Jun 2012 23:06:54 +0700, Ivan Shmakov wrote:
>  >> Thus, I'm curious, are there any plans to implement “off-line” NILFS
>  >> resizing?
> 
>  > Implementing Off-line resizing is a bit tough task because it
>  > requires a user space library to read internal meta data of the nilfs
>  > file system and append updated blocks to it.  This is almost
>  > equivalent to implementing kernel functions of nilfs in user land.
> 
>  > So, we have no concrete schedule now.
> 
> 	ACK, thanks.
> 
> 	I wonder, how complicated this task would be?  In particular, do
> 	I need to alter all the segments to resize filesystem, or only
> 	specific ones?  Also, are these internal metadata records just
> 	“a bunch of C structs”, or something more complex?

This needs at least the following tasks:

1) Update two super blocks to increase/decrease the number of total
   segments and the device size. (easy)

2) Update segment usage information to adjust free segment count of
   nilfs_sufile_header struct (sh_ncleansegs) which is written in
   the segment usage file. (Sadly not easy)

3) If truncating in-use segments, relocating blocks and updating
   disk address translation information are also needed. (very hard)


For reference, a discussion on this topic is found in the archives of
the list:

  http://marc.info/?t=128419843600003&r=1&w=2


Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

user-level toolkit for off-line operations

[Ivan Shmakov]

>>>>> Ryusuke Konishi writes:
>>>>> On Thu, 14 Jun 2012 11:22:17 +0700, Ivan Shmakov wrote:
>>>>> Ryusuke Konishi writes:

[…]

 >>> Implementing Off-line resizing is a bit tough task because it
 >>> requires a user space library to read internal meta data of the
 >>> nilfs file system and append updated blocks to it.

	… I guess that a user-level toolkit akin to e2fsprogs would be
	handy anyway.  (Shouldn't there be an fsck(8) for NILFS, BTW?)

	Other than resizing, there could be a feature to “split” a
	filesystem — take one or more “snapshot” checkpoints and make a
	copy of the parts of the filesystem “reachable” from these
	checkpoints on a distinct block device (perhaps of a differing
	size), which seems like one more way to do backups.

 >>> This is almost equivalent to implementing kernel functions of nilfs
 >>> in user land.

[…]

 >> I wonder, how complicated this task would be?  In particular, do I
 >> need to alter all the segments to resize filesystem, or only
 >> specific ones?  Also, are these internal metadata records just “a
 >> bunch of C structs”, or something more complex?

 > This needs at least the following tasks:

 > 1) Update two super blocks to increase/decrease the number of total
 > segments and the device size. (easy)

 > 2) Update segment usage information to adjust free segment count of
 > nilfs_sufile_header struct (sh_ncleansegs) which is written in
 > the segment usage file. (Sadly not easy)

 > 3) If truncating in-use segments, relocating blocks and updating disk
 > address translation information are also needed. (very hard)

	ACK.  (Fortunately, I'm not that interested in shrinking
	filesystems right now.)

 > For reference, a discussion on this topic is found in the archives of
 > the list:

 > http://marc.info/?t=128419843600003&r=1&w=2

	ACK, thanks!  I hope to take a closer look at this problem
	within two weeks or so.

	(JFTR: those reading via Gmane may access the thread via either
	of [1, 2]; the first message in the thread is [3].)

[1] http://comments.gmane.org/gmane.comp.file-systems.nilfs.user/397
[2] http://thread.gmane.org/gmane.comp.file-systems.nilfs.user/397/focus=1686
[3] news:BAEFA5609CC3AB4BAE1625CAD4C27E5C02986E1D-qPLjlnsG5hmCmmEZ8mJCX7uPtZ6Ynr+y@public.gmane.orga.com

-- 
FSF associate member #7257

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