[SPAM] resizing file system

[SPAM] resizing file system

[Munro, Fred]

[-- Attachment #1.1: Type: text/plain, Size: 223 bytes --]

I need to grow my partition and my FS.  In the future, I will may need
to shrink it.  Is there a way to resize my nilfs2 fs - something similar
to resize2fs for ext2/3?
 
Thanks for any help you can give me,
  - Fred

[-- Attachment #1.2: Type: text/html, Size: 805 bytes --]

[-- Attachment #2: Type: text/plain, Size: 158 bytes --]

_______________________________________________
users mailing list
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
https://www.nilfs.org/mailman/listinfo/users

Re: [SPAM] resizing file system

[Ryusuke Konishi]

Hi!
On Tue, 7 Apr 2009 10:57:23 -0600, "Munro, Fred" wrote:
> I need to grow my partition and my FS.  In the future, I will may need
> to shrink it.  Is there a way to resize my nilfs2 fs - something similar
> to resize2fs for ext2/3?

An experimental resize feature did exist, but it's not applicable to
the current version.  And, it didn't support shrinking.
So the feature you want is not available now.  (Sorry for inconvenience)

I think it's not difficult, but I'm busy with support of mainline
merging now.  I'd like to address such todo features again after it
gets settled.

Regards,
Ryusuke Konishi

Re: [SPAM] resizing file system

[Munro, Fred]

Hi,
> Hi!
On Tue, 7 Apr 2009 11:30:05, Ryusuke Konishi <ryusuke at osrg.net>
wrote:
> On Tue, 7 Apr 2009 10:57:23 -0600, "Munro, Fred" wrote:
> > I need to grow my partition and my FS.  In the future, I will may
need 
> > to shrink it.  Is there a way to resize my nilfs2 fs - something 
> > similar to resize2fs for ext2/3?
> 
> An experimental resize feature did exist, but it's not applicable to
the current version.  And, it didn't 
> support shrinking.
> So the feature you want is not available now.  (Sorry for
inconvenience)
> 
> I think it's not difficult, but I'm busy with support of mainline
merging now.  I'd like to address such todo 
> features again after it gets settled.
> 
> Regards,
> Ryusuke Konishi

Thanks for the quick and informative (though disappointing) response,
Ryusuke. I can certainly understand your priorities.

Best regards,
   - Fred

Re: resizing file system

[Matteo Frigo]

Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> writes:

> An experimental resize feature did exist, but it's not applicable to
> the current version.  And, it didn't support shrinking.
> So the feature you want is not available now.  (Sorry for inconvenience)

Ryusuke,

Thanks for developing nilfs2, it is a superb piece of work.

I am interested in the resize feature and willing to implement it, but I
need a little help.  My understanding of the nilfs2 source code in
2.6.35.4 is that in order to grow a file system it should be sufficient
to change s_nsegments in both superblocks while the file system is
unmounted.  If I understand correctly, the sufile grows automatically to
accomodate the additional segments because nilfs_sufile_alloc() calls
nilfs_sufile_get_segment_usage_block() with create=1, which grows the
sufile as necessary.

Is this interpretation correct?  If so, it should not be too hard to
code a little utility that grows an unmounted file system.  (Later we'll
worry about shrinking and online resize.)

You allude to an experimental resize feature.  Do you have code that I
can adapt to the current version?

Thanks,
Matteo Frigo

--
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: resizing file system

[Ryusuke Konishi]

Hi,
On Sat, 11 Sep 2010 05:46:29 -0400, Matteo Frigo wrote:
> Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> writes:
> 
> > An experimental resize feature did exist, but it's not applicable to
> > the current version.  And, it didn't support shrinking.
> > So the feature you want is not available now.  (Sorry for inconvenience)
> 
> Ryusuke,
> 
> Thanks for developing nilfs2, it is a superb piece of work.
> 
> I am interested in the resize feature and willing to implement it, but I
> need a little help.  My understanding of the nilfs2 source code in
> 2.6.35.4 is that in order to grow a file system it should be sufficient
> to change s_nsegments in both superblocks while the file system is
> unmounted.

Yes, right.

To be precise, you also have to move the secondary superblock, and
s_dev_size should be changed, too.  Anyway, all that's required for
the off-line expansion are these modifications.

> If I understand correctly, the sufile grows automatically to
> accomodate the additional segments because nilfs_sufile_alloc() calls
> nilfs_sufile_get_segment_usage_block() with create=1, which grows the
> sufile as necessary.

Exactly.

> Is this interpretation correct?  If so, it should not be too hard to
> code a little utility that grows an unmounted file system.  (Later we'll
> worry about shrinking and online resize.)
>
> You allude to an experimental resize feature.  Do you have code that I
> can adapt to the current version?

No, the experimental one got completely obsolete.  At least, we have
no applicable patch after the secondary super block was added.

If someone make a new one, I will apply that.

Recently, Jiro SEKIBA added library functions to modify super blocks.
I think, you can implement "nilfs-resize" by enhancing his work, by
amending "nilfs_sb_write" function.

The change is available on the latest util's git repo.

Thanks,
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

[PATCH] Compare device number rather than device name for mount check.

[Matteo Frigo]

To check whether a file system is mounted, nilfs-tune was comparing
the device name to the contents of /etc/mtab.  This check does not
detect a mounted file system when the device has multiple names, which
is a common case when using LVM.  (LVM creates symbolic links from
/dev/mapper/vg-lv to /dev/dm-X.)

This patch, borrowed from the analogous check in e2fsprogs, compares
the device number (field st_rdev of struct stat) rather than the
device name.

Signed-off-by: Matteo Frigo <athena-/JWCw35jmeM@public.gmane.org>
---
 configure.ac                 |    3 +-
 sbin/nilfs-tune/nilfs-tune.c |   69 +++++++++++++++++++++++++++++++----------
 2 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/configure.ac b/configure.ac
index af75142..963e2fd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,7 +37,8 @@ AC_HEADER_STDC
 AC_HEADER_SYS_WAIT
 AC_CHECK_HEADERS([fcntl.h libintl.h limits.h locale.h mntent.h paths.h \
 		  stdlib.h string.h strings.h sys/ioctl.h sys/mount.h \
-		  sys/time.h syslog.h unistd.h linux/types.h grp.h pwd.h])
+		  sys/time.h syslog.h unistd.h linux/types.h grp.h pwd.h \
+		  mntent.h])
 
 # Checks for typedefs, structures, and compiler characteristics.
 AC_C_CONST
diff --git a/sbin/nilfs-tune/nilfs-tune.c b/sbin/nilfs-tune/nilfs-tune.c
index 18513f2..5b7f030 100644
--- a/sbin/nilfs-tune/nilfs-tune.c
+++ b/sbin/nilfs-tune/nilfs-tune.c
@@ -58,6 +58,11 @@
 #include <pwd.h>
 #endif	/* HAVE_PWD_H */
 
+#ifdef HAVE_MNTENT_H
+#include <mntent.h>
+#endif
+
+#include <sys/stat.h>
 #include <ctype.h>
 
 #include <errno.h>
@@ -444,26 +449,57 @@ int modify_nilfs(char *device, struct nilfs_tune_options *opts)
 	return ret;
 }
 
-/* Code borrowed from nilfs2-util/sbin/mkfs/mkfs.c */
+/* check_mount() checks whether DEVICE is a mounted file system.
+   Returns 0 if the DEVICE is *not* mounted (which we consider a
+   successful outcome), and -1 if DEVICE is mounted or if the mount
+   status cannot be determined.
+
+   Derived from e2fsprogs/lib/ext2fs/ismounted.c
+   Copyright (C) 1995,1996,1997,1998,1999,2000 Theodore Ts'o,
+   LGPL v2
+*/
 static int check_mount(const char *device)
 {
-	FILE *fp;
-	char line[LINE_BUFFER_SIZE];
-
-	fp = fopen(MOUNTS, "r");
-	if (fp == NULL) {
+	struct mntent *mnt;
+	struct stat st_buf;
+	FILE *f;
+	dev_t file_dev = 0, file_rdev = 0;
+	ino_t file_ino = 0;
+
+	f = setmntent(MOUNTS, "r");
+	if (f == NULL) {
 		fprintf(stderr, "Error: cannot open %s!", MOUNTS);
-		return 1;
+		return -1;
 	}
 
-	while (fgets(line, LINE_BUFFER_SIZE, fp) != NULL) {
-		if (strncmp(strtok(line, " "), device, strlen(device)) == 0) {
-			fclose(fp);
-			return 1;
+	if (stat(device, &st_buf) == 0) {
+		if (S_ISBLK(st_buf.st_mode)) {
+			file_rdev = st_buf.st_rdev;
+		} else {
+			file_dev = st_buf.st_dev;
+			file_ino = st_buf.st_ino;
 		}
 	}
-	fclose(fp);
-	return 0;
+
+	while ((mnt = getmntent(f)) != NULL) {
+		if (mnt->mnt_fsname[0] != '/')
+			continue;
+		if (strcmp(device, mnt->mnt_fsname) == 0)
+			break;
+		if (stat(mnt->mnt_fsname, &st_buf) == 0) {
+			if (S_ISBLK(st_buf.st_mode)) {
+				if (file_rdev && (file_rdev == st_buf.st_rdev))
+					break;
+			} else {
+				if (file_dev && ((file_dev == st_buf.st_dev) &&
+						 (file_ino == st_buf.st_ino)))
+					break;
+			}
+		}
+	}
+
+	endmntent(f);
+	return (mnt == NULL) ? 0 : -1;
 }
 
 int main(int argc, char *argv[])
@@ -486,12 +522,11 @@ int main(int argc, char *argv[])
 		exit(EXIT_FAILURE);
 	}
 
-	if (!opts.force && opts.flags == O_RDWR && check_mount(device)) {
-		fprintf(stderr, "Warning: %s is currently mounted.\n"
+	if (!opts.force && opts.flags == O_RDWR && (check_mount(device) < 0)) {
+		fprintf(stderr, "ERROR: %s is currently mounted.  Aborting execution.\n"
 			"Running nilfs-tune on a mounted file system "
 			"may cause SEVERE damage.\n"
-			"You can force to modify file system by "
-			"\"-f\" option.\n",
+			"You can use the \"-f\" option to force this operation.\n",
 			device);
 		exit(EXIT_SUCCESS);
 	}
-- 
1.7.1


--
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: [PATCH] Compare device number rather than device name for mount check.

[Ryusuke Konishi]

Hi,
On Sat, 11 Sep 2010 15:40:12 -0400, Matteo Frigo wrote:
> To check whether a file system is mounted, nilfs-tune was comparing
> the device name to the contents of /etc/mtab.  This check does not
> detect a mounted file system when the device has multiple names, which
> is a common case when using LVM.  (LVM creates symbolic links from
> /dev/mapper/vg-lv to /dev/dm-X.)
> 
> This patch, borrowed from the analogous check in e2fsprogs, compares
> the device number (field st_rdev of struct stat) rather than the
> device name.
> 
> Signed-off-by: Matteo Frigo <athena-/JWCw35jmeM@public.gmane.org>

The patch looks sane except for the checkpatch warnings below:

> WARNING: line over 80 characters
> #526: FILE: nilfs-tune.c:526:
> +     	    fprintf(stderr, "ERROR: %s is currently mounted.  Aborting execution.\n"
> 
> WARNING: line over 80 characters
> #529: FILE: nilfs-tune.c:529:
> +		"You can use the \"-f\" option to force this operation.\n",
>  
> total: 0 errors, 2 warnings, 535 lines checked

I will adopt your patch with minor amendment.

Thank you.

Ryusuke Konishi

> ---
>  configure.ac                 |    3 +-
>  sbin/nilfs-tune/nilfs-tune.c |   69 +++++++++++++++++++++++++++++++----------
>  2 files changed, 54 insertions(+), 18 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index af75142..963e2fd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -37,7 +37,8 @@ AC_HEADER_STDC
>  AC_HEADER_SYS_WAIT
>  AC_CHECK_HEADERS([fcntl.h libintl.h limits.h locale.h mntent.h paths.h \
>  		  stdlib.h string.h strings.h sys/ioctl.h sys/mount.h \
> -		  sys/time.h syslog.h unistd.h linux/types.h grp.h pwd.h])
> +		  sys/time.h syslog.h unistd.h linux/types.h grp.h pwd.h \
> +		  mntent.h])
>  
>  # Checks for typedefs, structures, and compiler characteristics.
>  AC_C_CONST
> diff --git a/sbin/nilfs-tune/nilfs-tune.c b/sbin/nilfs-tune/nilfs-tune.c
> index 18513f2..5b7f030 100644
> --- a/sbin/nilfs-tune/nilfs-tune.c
> +++ b/sbin/nilfs-tune/nilfs-tune.c
> @@ -58,6 +58,11 @@
>  #include <pwd.h>
>  #endif	/* HAVE_PWD_H */
>  
> +#ifdef HAVE_MNTENT_H
> +#include <mntent.h>
> +#endif
> +
> +#include <sys/stat.h>
>  #include <ctype.h>
>  
>  #include <errno.h>
> @@ -444,26 +449,57 @@ int modify_nilfs(char *device, struct nilfs_tune_options *opts)
>  	return ret;
>  }
>  
> -/* Code borrowed from nilfs2-util/sbin/mkfs/mkfs.c */
> +/* check_mount() checks whether DEVICE is a mounted file system.
> +   Returns 0 if the DEVICE is *not* mounted (which we consider a
> +   successful outcome), and -1 if DEVICE is mounted or if the mount
> +   status cannot be determined.
> +
> +   Derived from e2fsprogs/lib/ext2fs/ismounted.c
> +   Copyright (C) 1995,1996,1997,1998,1999,2000 Theodore Ts'o,
> +   LGPL v2
> +*/
>  static int check_mount(const char *device)
>  {
> -	FILE *fp;
> -	char line[LINE_BUFFER_SIZE];
> -
> -	fp = fopen(MOUNTS, "r");
> -	if (fp == NULL) {
> +	struct mntent *mnt;
> +	struct stat st_buf;
> +	FILE *f;
> +	dev_t file_dev = 0, file_rdev = 0;
> +	ino_t file_ino = 0;
> +
> +	f = setmntent(MOUNTS, "r");
> +	if (f == NULL) {
>  		fprintf(stderr, "Error: cannot open %s!", MOUNTS);
> -		return 1;
> +		return -1;
>  	}
>  
> -	while (fgets(line, LINE_BUFFER_SIZE, fp) != NULL) {
> -		if (strncmp(strtok(line, " "), device, strlen(device)) == 0) {
> -			fclose(fp);
> -			return 1;
> +	if (stat(device, &st_buf) == 0) {
> +		if (S_ISBLK(st_buf.st_mode)) {
> +			file_rdev = st_buf.st_rdev;
> +		} else {
> +			file_dev = st_buf.st_dev;
> +			file_ino = st_buf.st_ino;
>  		}
>  	}
> -	fclose(fp);
> -	return 0;
> +
> +	while ((mnt = getmntent(f)) != NULL) {
> +		if (mnt->mnt_fsname[0] != '/')
> +			continue;
> +		if (strcmp(device, mnt->mnt_fsname) == 0)
> +			break;
> +		if (stat(mnt->mnt_fsname, &st_buf) == 0) {
> +			if (S_ISBLK(st_buf.st_mode)) {
> +				if (file_rdev && (file_rdev == st_buf.st_rdev))
> +					break;
> +			} else {
> +				if (file_dev && ((file_dev == st_buf.st_dev) &&
> +						 (file_ino == st_buf.st_ino)))
> +					break;
> +			}
> +		}
> +	}
> +
> +	endmntent(f);
> +	return (mnt == NULL) ? 0 : -1;
>  }
>  
>  int main(int argc, char *argv[])
> @@ -486,12 +522,11 @@ int main(int argc, char *argv[])
>  		exit(EXIT_FAILURE);
>  	}
>  
> -	if (!opts.force && opts.flags == O_RDWR && check_mount(device)) {
> -		fprintf(stderr, "Warning: %s is currently mounted.\n"
> +	if (!opts.force && opts.flags == O_RDWR && (check_mount(device) < 0)) {
> +		fprintf(stderr, "ERROR: %s is currently mounted.  Aborting execution.\n"
>  			"Running nilfs-tune on a mounted file system "
>  			"may cause SEVERE damage.\n"
> -			"You can force to modify file system by "
> -			"\"-f\" option.\n",
> +			"You can use the \"-f\" option to force this operation.\n",
>  			device);
>  		exit(EXIT_SUCCESS);
>  	}
> -- 
> 1.7.1
--
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: resizing file system

[Matteo Frigo]

Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> writes:

> To be precise, you also have to move the secondary superblock, and
> s_dev_size should be changed, too.  Anyway, all that's required for
> the off-line expansion are these modifications.

Ok, I hacked nilfs-tune to change s_dev_size, s_nsegments, and update
both superblocks.  I ``resized'' a 1GB file system into a 2GB file
system.  The file system mounts correctly, it has no apparent
corruption, and lssu shows all the new segments.  Moreover, the cleaner
recognizes and cycles through the full 2GB of segments.

However, the free space (as shown by df) is still 1GB, and the file
system runs out of space after storing 1GB of data, even though the
other 1GB of segments is shown to be empty by lssu.

I also tried updating s_free_blocks_count in the superblock,
but this quantity is apparently overwritten by the kernel after
mounting the file system.

My analysis of the situation is that the kernel still uses
NILFS_SUI(sufile)->ncleansegs from the sufile header, which I am not
changing.  How do I do that?

Thanks,
Matteo Frigo


--
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: resizing file system

[Ryusuke Konishi]

On Sat, 11 Sep 2010 19:31:18 -0400, Matteo Frigo wrote:
> Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> writes:
> 
> > To be precise, you also have to move the secondary superblock, and
> > s_dev_size should be changed, too.  Anyway, all that's required for
> > the off-line expansion are these modifications.
> 
> Ok, I hacked nilfs-tune to change s_dev_size, s_nsegments, and update
> both superblocks.  I ``resized'' a 1GB file system into a 2GB file
> system.  The file system mounts correctly, it has no apparent
> corruption, and lssu shows all the new segments.  Moreover, the cleaner
> recognizes and cycles through the full 2GB of segments.
> 
> However, the free space (as shown by df) is still 1GB, and the file
> system runs out of space after storing 1GB of data, even though the
> other 1GB of segments is shown to be empty by lssu.
> 
> I also tried updating s_free_blocks_count in the superblock,
> but this quantity is apparently overwritten by the kernel after
> mounting the file system.
> 
> My analysis of the situation is that the kernel still uses
> NILFS_SUI(sufile)->ncleansegs from the sufile header, which I am not
> changing.  How do I do that?

Ahh, sorry.  ncleansegs was written in the header block of sufile, and
we had to change it, too.

It's not difficult to change ncleansegs during mount if we tweaks the
kernel code, but I feel it's no longer the best.

Let me think if we can do it straight from userland.

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

Re: resizing file system

[Jiro SEKIBA]

Hi,

I think it would be good to have a generic libraries for other user land tools,
like parted, for the purpose to modify/tweek file system off line.
At least, resize/fsck/mkfs are the generic functionalities that parted
can handle.  So it's good if there is a library that can perform
those things to avoid implementing same thing all over the place.

One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
Still, contributers of libnilfs2 are countable, so maybe we can get agreements
from all contributers to change licence to LGPL2, isn't it?

Other utilities we can apply the libnilfs2, I can think of, are gvfs
modules to handle snapshot from nautilus.  I don't know much about
gvfs so it doesn't make sense..

Or maybe to create fuse driver for nilfs2 to mount snapshot without
super user privilege, which is always obstacles to handle snapshot
from end user's point of view.

In any cases, having generic library is key to propagate nilfs2 user land
implementations and which library is good to be LGPLed, I think.

Thanks,

regards

At Sun, 12 Sep 2010 11:26:50 +0900 (JST),
Ryusuke Konishi wrote:
> 
> On Sat, 11 Sep 2010 19:31:18 -0400, Matteo Frigo wrote:
> > Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org> writes:
> > 
> > > To be precise, you also have to move the secondary superblock, and
> > > s_dev_size should be changed, too.  Anyway, all that's required for
> > > the off-line expansion are these modifications.
> > 
> > Ok, I hacked nilfs-tune to change s_dev_size, s_nsegments, and update
> > both superblocks.  I ``resized'' a 1GB file system into a 2GB file
> > system.  The file system mounts correctly, it has no apparent
> > corruption, and lssu shows all the new segments.  Moreover, the cleaner
> > recognizes and cycles through the full 2GB of segments.
> > 
> > However, the free space (as shown by df) is still 1GB, and the file
> > system runs out of space after storing 1GB of data, even though the
> > other 1GB of segments is shown to be empty by lssu.
> > 
> > I also tried updating s_free_blocks_count in the superblock,
> > but this quantity is apparently overwritten by the kernel after
> > mounting the file system.
> > 
> > My analysis of the situation is that the kernel still uses
> > NILFS_SUI(sufile)->ncleansegs from the sufile header, which I am not
> > changing.  How do I do that?
> 
> Ahh, sorry.  ncleansegs was written in the header block of sufile, and
> we had to change it, too.
> 
> It's not difficult to change ncleansegs during mount if we tweaks the
> kernel code, but I feel it's no longer the best.
> 
> Let me think if we can do it straight from userland.
> 
> 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
> 
> 
> 

-- 
Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>
--
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: resizing file system

[Ryusuke Konishi]

Hi,
On Fri, 17 Sep 2010 18:15:59 +0900, Jiro SEKIBA wrote:
> Hi,
> 
> I think it would be good to have a generic libraries for other user land tools,
> like parted, for the purpose to modify/tweek file system off line.
> At least, resize/fsck/mkfs are the generic functionalities that parted
> can handle.  So it's good if there is a library that can perform
> those things to avoid implementing same thing all over the place.
> 
> One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
> Still, contributers of libnilfs2 are countable, so maybe we can get agreements
> from all contributers to change licence to LGPL2, isn't it?

Definitely yes.  I think we should migrate the licence of the library
to LGPL2.

One practical problem is that some of the source files derive the
kernel code, and they are licensed under GPLv2.

For example, nilfs2_fs.h and crc32.c are just such ones.

Do you think we need replacement for these?

> Other utilities we can apply the libnilfs2, I can think of, are gvfs
> modules to handle snapshot from nautilus.  I don't know much about
> gvfs so it doesn't make sense..
> 
> Or maybe to create fuse driver for nilfs2 to mount snapshot without
> super user privilege, which is always obstacles to handle snapshot
> from end user's point of view.

nilfs-utils v1 had an automount support.  Unfortunately, it is not
included in nilfs-utils-v2, but I think rewriting the script for the
v2 utils would help to ease this problem.

> In any cases, having generic library is key to propagate nilfs2 user land
> implementations and which library is good to be LGPLed, I think.

Reasonable.  At least, I agree with the licence migration.  Let's
consider how to avoid the minor license issue above.

Thanks,
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

Re: resizing file system

[Jiro SEKIBA]

Hi,

At Sat, 18 Sep 2010 01:20:00 +0900 (JST),
Ryusuke Konishi wrote:
> 
> Hi,
> On Fri, 17 Sep 2010 18:15:59 +0900, Jiro SEKIBA wrote:
> > Hi,
> > 
> > I think it would be good to have a generic libraries for other user land tools,
> > like parted, for the purpose to modify/tweek file system off line.
> > At least, resize/fsck/mkfs are the generic functionalities that parted
> > can handle.  So it's good if there is a library that can perform
> > those things to avoid implementing same thing all over the place.
> > 
> > One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
> > Still, contributers of libnilfs2 are countable, so maybe we can get agreements
> > from all contributers to change licence to LGPL2, isn't it?
> 
> Definitely yes.  I think we should migrate the licence of the library
> to LGPL2.
> 
> One practical problem is that some of the source files derive the
> kernel code, and they are licensed under GPLv2.
> 
> For example, nilfs2_fs.h and crc32.c are just such ones.
> 
> Do you think we need replacement for these?

We could choose to change the licence as LGPL like mqueue.h (*1).
However, we may be able to think that license of nilfs2_fs.h won't affect
license of user land tools.  At least, Linus stated that "There's a
clarification that user-space programs that use the standard system call
interfaces aren't considered derived works, ..." (*2). 

*1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/mqueue.h;hb=HEAD
*2) http://kerneltrap.org/node/1735

While, crc32.c must be replaced other implementation :(.
I'll search lgpled implementation.

thanks,

regards,

> > Other utilities we can apply the libnilfs2, I can think of, are gvfs
> > modules to handle snapshot from nautilus.  I don't know much about
> > gvfs so it doesn't make sense..
> > 
> > Or maybe to create fuse driver for nilfs2 to mount snapshot without
> > super user privilege, which is always obstacles to handle snapshot
> > from end user's point of view.
> 
> nilfs-utils v1 had an automount support.  Unfortunately, it is not
> included in nilfs-utils-v2, but I think rewriting the script for the
> v2 utils would help to ease this problem.
> 
> > In any cases, having generic library is key to propagate nilfs2 user land
> > implementations and which library is good to be LGPLed, I think.
> 
> Reasonable.  At least, I agree with the licence migration.  Let's
> consider how to avoid the minor license issue above.
> 
> Thanks,
> 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
> 
> 
> 

-- 
Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>
--
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: resizing file system

[Ryusuke Konishi]

Hi,
On Mon, 27 Sep 2010 19:59:54 +0900, Jiro SEKIBA wrote:
> Hi,
> 
> At Sat, 18 Sep 2010 01:20:00 +0900 (JST),
> Ryusuke Konishi wrote:
> > 
> > Hi,
> > On Fri, 17 Sep 2010 18:15:59 +0900, Jiro SEKIBA wrote:
> > > Hi,
> > > 
> > > I think it would be good to have a generic libraries for other user land tools,
> > > like parted, for the purpose to modify/tweek file system off line.
> > > At least, resize/fsck/mkfs are the generic functionalities that parted
> > > can handle.  So it's good if there is a library that can perform
> > > those things to avoid implementing same thing all over the place.
> > > 
> > > One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
> > > Still, contributers of libnilfs2 are countable, so maybe we can get agreements
> > > from all contributers to change licence to LGPL2, isn't it?
> > 
> > Definitely yes.  I think we should migrate the licence of the library
> > to LGPL2.
> > 
> > One practical problem is that some of the source files derive the
> > kernel code, and they are licensed under GPLv2.
> > 
> > For example, nilfs2_fs.h and crc32.c are just such ones.
> > 
> > Do you think we need replacement for these?
> 
> We could choose to change the licence as LGPL like mqueue.h (*1).
> However, we may be able to think that license of nilfs2_fs.h won't affect
> license of user land tools.

> At least, Linus stated that "There's a
> clarification that user-space programs that use the standard system call
> interfaces aren't considered derived works, ..." (*2). 
>
> *1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/mqueue.h;hb=HEAD
> *2) http://kerneltrap.org/node/1735

"unistd.h" is distributed under LGPL.  So, the above Linus' statement
sounds like saying just fundamental charateristics of LGPL.

The point of "nilfs2_fs.h" issue differs from that.  A copy of
nilfs2_fs.h is actually included in nilfs-utils, and the nilfs library
is depending on the copy.

The "mqueue.h" solution seems to be an approved manner (sigh).

Another solution is extracting requisites from "nilfs2_fs.h" and
rewriting them under LGPL for the library and userland programs.

Or, do you know any examples of GPL header file whose library is
licensed under LGPL?

> While, crc32.c must be replaced other implementation :(.
> I'll search lgpled implementation.

OK, let's replace it with a compatible one if we change the library
license to LGPL.

Thanks,
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

Re: resizing file system

[Jiro SEKIBA]

Hi, 

Based on the situation I've searched for a few days,
I conclude that it's better to change license of the nilfs2_fs.h header.
I'll comment it inline.

At Tue, 28 Sep 2010 01:01:38 +0900 (JST),
Ryusuke Konishi wrote:
> 
> Hi,
> On Mon, 27 Sep 2010 19:59:54 +0900, Jiro SEKIBA wrote:
> > Hi,
> > 
> > At Sat, 18 Sep 2010 01:20:00 +0900 (JST),
> > Ryusuke Konishi wrote:
> > > 
> > > Hi,
> > > On Fri, 17 Sep 2010 18:15:59 +0900, Jiro SEKIBA wrote:
> > > > Hi,
> > > > 
> > > > I think it would be good to have a generic libraries for other user land tools,
> > > > like parted, for the purpose to modify/tweek file system off line.
> > > > At least, resize/fsck/mkfs are the generic functionalities that parted
> > > > can handle.  So it's good if there is a library that can perform
> > > > those things to avoid implementing same thing all over the place.
> > > > 
> > > > One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
> > > > Still, contributers of libnilfs2 are countable, so maybe we can get agreements
> > > > from all contributers to change licence to LGPL2, isn't it?
> > > 
> > > Definitely yes.  I think we should migrate the licence of the library
> > > to LGPL2.
> > > 
> > > One practical problem is that some of the source files derive the
> > > kernel code, and they are licensed under GPLv2.
> > > 
> > > For example, nilfs2_fs.h and crc32.c are just such ones.
> > > 
> > > Do you think we need replacement for these?
> > 
> > We could choose to change the licence as LGPL like mqueue.h (*1).
> > However, we may be able to think that license of nilfs2_fs.h won't affect
> > license of user land tools.
> 
> > At least, Linus stated that "There's a
> > clarification that user-space programs that use the standard system call
> > interfaces aren't considered derived works, ..." (*2). 
> >
> > *1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/mqueue.h;hb=HEAD
> > *2) http://kerneltrap.org/node/1735
> 
> "unistd.h" is distributed under LGPL.  So, the above Linus' statement
> sounds like saying just fundamental charateristics of LGPL.

I interpreted his statement different way, that using standard interface
of kernel is using system call or ioctl.  Using those functionality 
requires including headers for binary compatibility.

> The point of "nilfs2_fs.h" issue differs from that.  A copy of
> nilfs2_fs.h is actually included in nilfs-utils, and the nilfs library
> is depending on the copy.
> 
> The "mqueue.h" solution seems to be an approved manner (sigh).
> 
> Another solution is extracting requisites from "nilfs2_fs.h" and
> rewriting them under LGPL for the library and userland programs.
> 
> Or, do you know any examples of GPL header file whose library is
> licensed under LGPL?

libv4l includes videodev2.h which is GPL, but is released under LGPL.
 http://freshmeat.net/projects/libv4l

However, that is the only LGPL library I found  which includes GPL header.
Other libraries intentionally or unintentionally don't include GPL headers.

Actually, I realized that some of exported headers of linux kernel are
not GPL, but like LGPL, BSD, MIT.  Or even no license declaration.

Here is the diff of the kernel that merely changes license of header
to avoid the license issues we have been talking.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=19b3eecc21b65a24b0aae2684ca0c8e1b99ef802

So non-GPLed header is common way to export linux headers.

thanks,

regards

> > While, crc32.c must be replaced other implementation :(.
> > I'll search lgpled implementation.
> 
> OK, let's replace it with a compatible one if we change the library
> license to LGPL.
> 
> Thanks,
> 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
> 
> 
> 


-- 
Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>
--
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: resizing file system

[Ryusuke Konishi]

On Fri, 01 Oct 2010 13:21:10 +0900, Jiro SEKIBA wrote:
> Hi, 
> 
> Based on the situation I've searched for a few days,
> I conclude that it's better to change license of the nilfs2_fs.h header.
> I'll comment it inline.

OK, I'll post the patch to change the license, and will send it for
the next merge window unless there are objections.

Thanks,
Ryusuke Konishi
 
> At Tue, 28 Sep 2010 01:01:38 +0900 (JST),
> Ryusuke Konishi wrote:
> > 
> > Hi,
> > On Mon, 27 Sep 2010 19:59:54 +0900, Jiro SEKIBA wrote:
> > > Hi,
> > > 
> > > At Sat, 18 Sep 2010 01:20:00 +0900 (JST),
> > > Ryusuke Konishi wrote:
> > > > 
> > > > Hi,
> > > > On Fri, 17 Sep 2010 18:15:59 +0900, Jiro SEKIBA wrote:
> > > > > Hi,
> > > > > 
> > > > > I think it would be good to have a generic libraries for other user land tools,
> > > > > like parted, for the purpose to modify/tweek file system off line.
> > > > > At least, resize/fsck/mkfs are the generic functionalities that parted
> > > > > can handle.  So it's good if there is a library that can perform
> > > > > those things to avoid implementing same thing all over the place.
> > > > > 
> > > > > One big problem for parted is that parted is GPL3 and libnilfs2 is GPL2 X).
> > > > > Still, contributers of libnilfs2 are countable, so maybe we can get agreements
> > > > > from all contributers to change licence to LGPL2, isn't it?
> > > > 
> > > > Definitely yes.  I think we should migrate the licence of the library
> > > > to LGPL2.
> > > > 
> > > > One practical problem is that some of the source files derive the
> > > > kernel code, and they are licensed under GPLv2.
> > > > 
> > > > For example, nilfs2_fs.h and crc32.c are just such ones.
> > > > 
> > > > Do you think we need replacement for these?
> > > 
> > > We could choose to change the licence as LGPL like mqueue.h (*1).
> > > However, we may be able to think that license of nilfs2_fs.h won't affect
> > > license of user land tools.
> > 
> > > At least, Linus stated that "There's a
> > > clarification that user-space programs that use the standard system call
> > > interfaces aren't considered derived works, ..." (*2). 
> > >
> > > *1) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/mqueue.h;hb=HEAD
> > > *2) http://kerneltrap.org/node/1735
> > 
> > "unistd.h" is distributed under LGPL.  So, the above Linus' statement
> > sounds like saying just fundamental charateristics of LGPL.
> 
> I interpreted his statement different way, that using standard interface
> of kernel is using system call or ioctl.  Using those functionality 
> requires including headers for binary compatibility.
> 
> > The point of "nilfs2_fs.h" issue differs from that.  A copy of
> > nilfs2_fs.h is actually included in nilfs-utils, and the nilfs library
> > is depending on the copy.
> > 
> > The "mqueue.h" solution seems to be an approved manner (sigh).
> > 
> > Another solution is extracting requisites from "nilfs2_fs.h" and
> > rewriting them under LGPL for the library and userland programs.
> > 
> > Or, do you know any examples of GPL header file whose library is
> > licensed under LGPL?
> 
> libv4l includes videodev2.h which is GPL, but is released under LGPL.
>  http://freshmeat.net/projects/libv4l
> 
> However, that is the only LGPL library I found  which includes GPL header.
> Other libraries intentionally or unintentionally don't include GPL headers.
> 
> Actually, I realized that some of exported headers of linux kernel are
> not GPL, but like LGPL, BSD, MIT.  Or even no license declaration.
> 
> Here is the diff of the kernel that merely changes license of header
> to avoid the license issues we have been talking.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=19b3eecc21b65a24b0aae2684ca0c8e1b99ef802
> 
> So non-GPLed header is common way to export linux headers.
> 
> thanks,
> 
> regards
> 
> > > While, crc32.c must be replaced other implementation :(.
> > > I'll search lgpled implementation.
> > 
> > OK, let's replace it with a compatible one if we change the library
> > license to LGPL.
> > 
> > Thanks,
> > 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
> > 
> > 
> > 
> 
> 
> -- 
> Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>
--
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