Re: resizing file system
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jiro SEKIBA j...@unicus.jp -- To unsubscribe from this list: send the line unsubscribe linux-nilfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: resizing file system
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: resizing file system
Ryusuke Konishi ryus...@osrg.net 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: resizing file system
On Sat, 11 Sep 2010 19:31:18 -0400, Matteo Frigo wrote: Ryusuke Konishi ryus...@osrg.net 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
