Hi,
Le 01/10/2020 à 11:00, Jean-Pierre André a écrit :
> 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
Here goes:
Dumping Inode 2 (0x2)
Upd. Seq. Array Off.: 48 (0x30)
Upd. Seq. Array Count: 3 (0x3)
Upd. Seq. Number: 80 (0x50)
LogFile Seq. Number: 0x2001721
MFT Record Seq. Numb.: 2 (0x2)
Number of Hard Links: 1 (0x1)
Attribute Offset: 56 (0x38)
MFT Record Flags: IN_USE
Bytes Used: 344 (0x158) bytes
Bytes Allocated: 1024 (0x400) bytes
Next Attribute Instance: 4 (0x4)
MFT Padding: 00 00
Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 2 (0x2)
Attribute length: 96 (0x60)
Resident: Yes
Name length: 0 (0x0)
Name offset: 24 (0x18)
Attribute flags: 0x0000
Attribute instance: 0 (0x0)
Data size: 72 (0x48)
Data offset: 24 (0x18)
Resident flags: 0x00
ReservedR: 0 (0x0)
File Creation Time: Tue Sep 22 20:29:47 2020 UTC
File Altered Time: Tue Sep 22 20:29:47 2020 UTC
MFT Changed Time: Tue Sep 22 20:29:47 2020 UTC
Last Accessed Time: Tue Sep 22 20:29:47 2020 UTC
File attributes: HIDDEN SYSTEM (0x00000006)
Maximum versions: 0
Version number: 0
Class ID: 0
User ID: 0 (0x0)
Security ID: 256 (0x100)
Quota charged: 0 (0x0)
Update Sequence Number: 0 (0x0)
Dumping attribute $FILE_NAME (0x30) from mft record 2 (0x2)
Attribute length: 112 (0x70)
Resident: Yes
Name length: 0 (0x0)
Name offset: 24 (0x18)
Attribute flags: 0x0000
Attribute instance: 2 (0x2)
Data size: 82 (0x52)
Data offset: 24 (0x18)
Resident flags: 0x01
ReservedR: 0 (0x0)
Parent directory: 5 (0x5)
File Creation Time: Tue Sep 22 20:29:47 2020 UTC
File Altered Time: Tue Sep 22 20:29:47 2020 UTC
MFT Changed Time: Tue Sep 22 20:29:47 2020 UTC
Last Accessed Time: Tue Sep 22 20:29:47 2020 UTC
Allocated Size: 67108864 (0x4000000)
Data Size: 67108864 (0x4000000)
Filename Length: 8 (0x8)
File attributes: HIDDEN SYSTEM (0x00000006)
Namespace: Win32 & DOS
Filename: '$LogFile'
Dumping attribute $DATA (0x80) from mft record 2 (0x2)
Attribute length: 72 (0x48)
Resident: No
Name length: 0 (0x0)
Name offset: 64 (0x40)
Attribute flags: 0x0000
Attribute instance: 1 (0x1)
Lowest VCN 0 (0x0)
Highest VCN: 16383 (0x3fff)
Mapping pairs offset: 64 (0x40)
Compression unit: 0 (0x0)
Data size: 67108864 (0x4000000)
Allocated size: 67108864 (0x4000000)
Initialized size: 67108864 (0x4000000)
Runlist: VCN LCN Length
0x0 0xbbd74 0x4000
End of inode reached
Total runs: 1 (fragments: 1)
I have no idea what I can conclude from this output...
Please shed some light.
Best regards,
Didier
PS this Windows has only been installed in a Qemu VM
for testing purposes. I just ran Windows udate once,
and also disabled fast boot withy this command:
powercfg /h off
> Regards
>
> Jean-Pierre
>
>>
>> Best regards,
>>
>> Didier
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
