On Thu, Apr 30, 2015 at 11:13:16AM -0400, Theodore Ts'o wrote: > On Thu, Apr 30, 2015 at 07:12:04PM +0900, Chanho Park wrote: > > > > In my situation, I usually use the "resize2fs -M" when making a tizen > > platform image. As you know, like android, tizen also uses ext4 filesystem > > and flash the image from bootloader. Instead of flashing full image size, we > > only flash shrinked filesystem image to reduce flashing time and want to > > avoid download huge files. If the partition size is 3GB, we'll make a 3GB > > loop image and fill files into it. And I shrink the loop image to the > > minimum size and flash it to my phone. When first booting, the system will > > do resizing the partition to 3GB original size. > > What I would recommend is to estimate how big the file system needs to > doing a "du -s" over the directory that you want to preload onto the > file system size, add say, 5% or so the file system metadata, and then > create the file system that way. If the file system is close enough > to the right size, then resize2fs -M is much more likely to shrink the > file system to its minimal size, and also reduce the file /me wonders if the script I threw into the last patchbomb would help? http://patchwork.ozlabs.org/patch/457482/ If you intend to write to the FS after it's been expanded into the target device, you should turn journalling on /after/ the expand operation. --D > fragmentation that results from it. (One of the better uses for using > resize2fs to slightly shrink a file system was to make room for the > LVM table at the end of the device, for example. It's when you try to > take, say, a 1TB file system and shrink to a few megabytes that > resize2fs doesn't do a great job, because it really wasn't engineered > for that use case, and it's hard enough to make sure it does so in a > efficient and robust manner as it is.) > > You can then take that file system and shrink to a size far larger > than what it was originally created as --- that works much better than > taking a large empty file system, shrinking it down to its minimal > size, and then expanding it to something bigger. If necessary, you > can use the "mke2fs -E resize=15T" option to make sure enough metadata > blocks have been reserved so the file system can be expanded as much > as you would like. By default we reserve enough metadata blocks for > the file system to grow by a factor of a thousand, so if you create a > super-tiny file system and then expect to grow it to a multi-TB size, > that mke2fs option will be useful. It's not strictly necessary for > ext4 (although it was required for ext3), but it will result in a > slightly more efficient file system that will mount more quickly under > ext4. > > So if your Tizen image is, say, 390 megabytes, I'd suggest creating a > 400 megabyte file system, and load that up with the image. If you > then use resize2fs -M, it should shirnk it down to something much > closer to 390M. > > I suspect you will find that the resulting image will be far more > efficient than trying to start with a 3GB file system, shrink it down > to 400M, and then expand it backup to 3GB. > > Best regards, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
