On Mon, Feb 04, 2013 at 02:09:55PM +0100, Jean-Pierre André wrote: > Hi, > > Richard W.M. Jones wrote: > >[I'm not sure this is a real bug, but here we go ...] > >[https://bugzilla.redhat.com/show_bug.cgi?id=895946] > > > >It was reported to me that when you resize a filesystem down to a > >smaller size then back up to the original size, the number of blocks > >(as reported by statvfs) is one less than expected. > > > >Attached is a small guestfish script that demonstrates this: > > > > $ /tmp/ntfsresize.sh > > blocks: 25568 > > Resizing filesystem to 10000 blocks ... > > blocks: 9999 > > Resizing filesystem to original (full) size ... > > blocks: 25567 > > > >Here is the ntfsresize command that libguestfs runs: > >https://github.com/libguestfs/libguestfs/blob/master/daemon/ntfs.c#L69 > > > >(Note we're using a rather old version of ntfs-3g, > >ntfs-3g-2012.1.15-5.fc18.x86_64. I'm going to try a more recent > >version shortly). > > > >Is this expected? I imagine that one block could "go missing" for the > >superblock or whatever overhead. However it's rather unusual that the > >size changes from the original size. > > This is just a matter of putting the correct definition > to the size argument. > > In a partition with an ntfs file system, the last *sector* > is reserved for a backup boot sector (only used for > recovering the actual boot sector). The remaining > sectors can be used by the file system, which groups > them by *clusters*, generally leaving a few unused > sectors (I avoid using "blocks" which is not an ntfs > concept). > > In one of my file systems I have : > > Partition sectors 68934852 (0x41bdcc4), sector size 512 > File system sectors 68934851 (0x41bdcc3) > File system capacity 35294643712 bytes (35 GB) > Hidden sectors 409593303 (0x1869e5d7) > Clusters 8616856 (0x837b98), cluster size 4096 > > You see that file system sectors is one less than > partition sectors, and the cluster grouping leads > to 8616856*8 = 68934848 used sectors, which means > there are 3 unused sectors. > > Now, the argument size in ntfsresize is the *partition > size*, whereas df(1) or statvfs(3) will give you a number > of 1K or 512b blocks really used by the file system. > In the above example there is a difference of 4 sectors. > > I have changed the description of the size argument > of ntfsresize to hopefully clarify things (not yet released). > > "Resize filesystem to fit in a partition whose size is > SIZE[k|M|G] bytes by shifting its end and keeping its beginning > unchanged. The filesystem size is set to be at least one sector > smaller than the partition."
Thanks - I will also mark this as not being a bug, and point to this very clear explanation. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
