Hi,
Didier Spaier wrote on 10/1/20 1:31 AM:
Hi,
Le 30/09/2020 à 09:40, Jean-Pierre André a écrit :
Hi,
Didier Spaier wrote on 9/30/20 12:50 AM:
Hello,
I am the maintainer of the Slint distribution, cf. https://slint.fr
I want to provide in our installer the ability to shrink a NTFS file system and
associated partition to make room for Slint alongside Windows.
But when I check the minimum size of the FS from Windows 10 (tested in a Qemu
VM) I get 20375928832 bytes whereas ntfsresize gives 13357295660.
The size returned by ntfsresize is the space actually used,
IOW the space that would be used if all the data would be
packed at the beginning of the device. That is generally
not reachable because relocating data causes extra
fragmentation which requires some more space.
Now, if the partition is a Windows partition, it needs more
space for breathing. During a Windows update, two copies
of the system are temporarily stored. The figure you got from
Windows probably accounts for that extra space.
ntfscluster tells me that no inode is found after cluster number 3479395, i.e.
byte number 1422934016.
How did you get this ?
It was an approximation. Here is a script to get a more precise value:
#!/bin/sh
[...]
It gave (with the last line added):
Minimum with no further inode is 3526478 Clusters or 14444453888 bytes
Minimum according to ntfsresize is 3190218 Clusters or 13067132928 bytes
Minimum according to Windows: 19562 MiB or 2052243712 bytes.
According to the metadata (shown below), this is a 87GB
partition, with 13GB used (15%) or 18139957 free clusters
from a total of 21330175.
The value returned by ntfsresize means just that (3190218
clusters = 21330175-18139957).
Your script tells that the last cluster used is number 3526478,
which means only the lower 16.5% of space is used. The
partition has probably been defragmented recently (or it
has only been used for adding files).
Now, if Windows recommends 20GB, it must have reserved
a safety margin. It has also been noted that Windows is
unable to relocate some files, such as the update journal
($LogFile), but that does not seem to be the case here.
Of course, when you shrink a partition, you have to take into
account how the partition will be used later.
This is what your script returns for my Windows 10 system
partition :
Volume size is 16726015 Clusters or 68509757440 bytes
Minimum with no further inode is 13769905 Clusters or 56401530880 bytes
Minimum according to ntfsresize is 4694988 Clusters or 19230670848 bytes
The used space is currently 19GB (28%), but this is
scattered over the partition, and I have seen this to be
42GB after a system update, so better not to shrink it
aggressively.
The result should be accurate, plus or minus one cluster.
I would need the output of "ntfsinfo -fm /dev/xxx" to give
an explanation.
Below:
Volume Information
Name of device: /dev/sda4
Device state: 11
Volume Name:
Volume State: 91
Volume Flags: 0x0000
Volume Version: 3.1
Sector Size: 512
Cluster Size: 4096
Index Block Size: 4096
Volume Size in Clusters: 21330175
MFT Information
MFT Record Size: 1024
MFT Zone Multiplier: 0
MFT Data Position: 24
MFT Zone Start: 786432
MFT Zone End: 3452703
MFT Zone Position: 786432
Current Position in First Data Zone: 3452703
Current Position in Second Data Zone: 0
Allocated clusters 23744 (0,1%)
LCN of Data Attribute for FILE_MFT: 786432
FILE_MFTMirr Size: 4
LCN of Data Attribute for File_MFTMirr: 2
Size of Attribute Definition Table: 2560
Number of Attached Extent Inodes: 0
FILE_Bitmap Information
FILE_Bitmap MFT Record Number: 6
State of FILE_Bitmap Inode: 80
Length of Attribute List: 0
Number of Attached Extent Inodes: 0
FILE_Bitmap Data Attribute Information
Decompressed Runlist: not done yet
Base Inode: 6
Attribute Types: not done yet
Attribute Name Length: 0
Attribute State: 3
Attribute Allocated Size: 2666496
Attribute Data Size: 2666272
Attribute Initialized Size: 2666272
Attribute Compressed Size: 0
Compression Block Size: 0
Compression Block Size Bits: 0
Compression Block Clusters: 0
Free Clusters: 18139957 (85,0%)
Should I understand that ntfsresize is not ready for Windows 10, or do I miss
something obvious? I would prefer the latter ;)
Please report any bug that you may know, otherwise it
will probably not be fixed...
I am not saying that there is a bug, rather trying to find out
if/how I could use nfs-3g to find the same minium size as displayed
by Windows 10.
Sorry, I have no information about how Windows 10
computes the minimum size. The location of the $LogFile
may however give a clue. Just do :
ntfsinfo -fvi 2 /dev/xxx
Regards
Jean-Pierre
Best regards,
Didier
_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel