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 ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel