Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Windows 2016 NTFS LZX compressie niet toegestaan?

Pagina: 1
Acties:

  • Fairy
  • Registratie: Januari 2001
  • Niet online
Ik heb een Windows 2016 servertje.

De dataschijven heb ik vers geformatteerd onder NTFS (4k).
Nu wil ik de backup comprimeren met compact en dan de LZX methode.

Onder de Windows 10 machines heb ik dit probleemloos kunnen doen, maar onder Windows 2016 lukt dit niet.

Ik heb een testje gedaan en krijg de volgende fout:

code:
1
2
3
4
5
6
7
8
9
10
11
12
G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500>compact /c /s /a /EXE:LZX

 Compressing files in G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\

KProIJPaper_CaIP8500_v1.icm [ERR]
KProIJPaper_CaIP8500_v1.icm: The file system does not support compression.

0 files within 1 directories were compressed.
0 total bytes of data are stored in 0 bytes.
The compression ratio is 1,0 to 1.

G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500>


Hij pakt geen enkele methode. Doe ik echter compressie via de GUI dan werkt dat wel, maar dat is beperkt tot de meest simpele compressievariant. Het filesystem zou geen compressie ondersteunen, maar dit is dus niet het geval.

De NTFS versie is wel correct naar mijn idee:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
G:\>fsutil fsinfo ntfsinfo g:
NTFS Volume Serial Number :        0x7e12eaae12ea6a9b
NTFS Version   :                   3.1
LFS Version    :                   2.0
Number Sectors :                   0x000000015d4c97ff
Total Clusters :                   0x000000002ba992ff
Free Clusters  :                   0x00000000075e1995
Total Reserved :                   0x0000000000000400
Bytes Per Sector  :                512
Bytes Per Physical Sector :        4096
Bytes Per Cluster :                4096
Bytes Per FileRecord Segment    :  1024
Clusters Per FileRecord Segment :  0
Mft Valid Data Length :            0x0000000013d40000
Mft Start Lcn  :                   0x00000000000c0000
Mft2 Start Lcn :                   0x0000000000000002
Mft Zone Start :                   0x000000001fadd480
Mft Zone End   :                   0x000000001fae2780
Max Device Trim Extent Count :     0
Max Device Trim Byte Count :       0x0
Max Volume Trim Extent Count :     62
Max Volume Trim Byte Count :       0x40000000
Resource Manager Identifier :     0D48CDC6-511D-11E8-A2F6-3085A93CB2BB


De help van Compact laat echter wel LZX een XPRESS4K t/m 16K zien, dus ik verwacht ook dat Windows 2016 dit hoort te supporten.

PS. Op de bootschijf blijkt de compressie wél te werken...

Kan iemand hier iets zinnigs over zeggen?

  • akimosan
  • Registratie: Augustus 2003
  • Niet online
1) Ik denk dat het iets te maken heeft met clustersizes op de volumes? Je zou even wat testen kunnen doen met verschillende typen (even wat kleine virtual diskjes aanmaken en testen maar)

https://social.technet.mi...es?forum=WinServerPreview

2) Sla je ook daadwerkelijk EXE files op als backup die je gecomprimeerd wilt hebben? En lees je dan regelmatig van die exe files? Gezien onderstaande begrijp ik het nut/doel niet helemaal.

/EXE Use compression optimized for executable files which are read
frequently and not modified. Supported algorithms are:
XPRESS4K (fastest) (default)
XPRESS8K
XPRESS16K
LZX (most compact)

3) Heeft het nog nut als je waarschijnlijk toch grotere clustersizes gaat gebruiken? Grotere data bestanden zijn vaak "media" bestanden en dan wordt ook vaak al compressie toegepast (JPG, MP3, 4, etc) dus file compressie gaat waarschijnlijk weinig extra ruimte opleveren.

  • Fairy
  • Registratie: Januari 2001
  • Niet online
Clustersizes zijn gelijk, allemaal 4K. Enkel de C schijf is een SSD, de andere schijven zijn 3TB WD RED schijven.

/EXE:LZX heeft naar mijn weten niet specifiek exe bestanden nodig, want de compressie werkt bijzonder goed op alle soorten bestanden. Waarom Windows het 'executable' noemt is mij ook een raadsel, want je kan alle bestanden comprimeren.

Overigens, als ik exact hetzelfde bestand als in het voorbeeld naar de C schijf kopieer en daar hetzelfde commando uitvoer, dan comprimeert hij wél gewoon, maar op de D, E, F, G schijf werkt het niet. Ook in elevated command.

Zie hier:

code:
1
2
3
4
5
6
7
8
9
10
11
C:\test>compact /c /s /a /EXE:LZX

 Compressing files in C:\test\

KProIJPaper_CaIP8500_v1.icm   1719674 :   1302528 = 1,3 to 1 [OK]

1 files within 1 directories were compressed.
1.719.674 total bytes of data are stored in 1.302.528 bytes.
The compression ratio is 1,3 to 1.

C:\test>


Hetzelfde op de dataschijf:
code:
1
2
3
4
5
6
7
8
9
10
11
12
G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\test>compact /c /s /a /EXE:LZX

 Compressing files in G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\test\

KProIJPaper_CaIP8500_v1.icm [ERR]
KProIJPaper_CaIP8500_v1.icm: The file system does not support compression.

0 files within 1 directories were compressed.
0 total bytes of data are stored in 0 bytes.
The compression ratio is 1,0 to 1.

G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\test>


Als ik default NTFS compressie uitvoer, dan accepteert hij dat wel :?

code:
1
2
3
4
5
6
7
8
9
10
11
G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\test>compact /c /s

 Setting the directory G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\test\ to compress new files [OK]

 Compressing files in G:\DATA2.BACKUP\Software\ICC-Profiles-iP8500\test\

KProIJPaper_CaIP8500_v1.icm   1719674 :   1630208 = 1,1 to 1 [OK]

2 files within 2 directories were compressed.
1.719.674 total bytes of data are stored in 1.630.208 bytes.
The compression ratio is 1,1 to 1.


Alleen dat wil ik niet, want die ratio is verwaarloosbaar.

[ Voor 66% gewijzigd door Fairy op 07-05-2018 20:10 ]


  • akimosan
  • Registratie: Augustus 2003
  • Niet online
Ok, ik ben er even mee gaan testen en de uitslag is dat het me ook niet zomaar lukt. Ik heb achtereenvolgens een virtual disk gemaakt op server 2016 en op win10 en deze NTFS geformateerd.

De 1e disk kon ik niet eens formatteren met een clustersize kleiner dan 4096 bytes:
"Cluster size must be a multiplication of the physical sector size (4096 bytes)"

Vervolgens heb ik een virtual disk aangemaakt op win10, clustersize ook op 4096 bytes.
disk ontkoppeld, VHDX bestand gekopieerd naar Server 2016, daar gemount.
LZX compressie geprobeerd: filesystem does not support compression.
En dat dus op dezelfde "disk", dus het zit niet zomaar in het bestandsysteem,

Nog een keer, maar dan iets anders:
virtual disk aangemaakt op win10, clustersize ook op 4096 bytes.
LZX compressie toegepast. Ging prima.
disk ontkoppeld, VHDX bestand gekopieerd naar Server 2016, daar gemount.
Lezen:OK, kopiëren, etc, OK
Files gedecomprimeerd: WERKT!
LZX compressie opnieuw: WERKT!
Dus het eerst uitvoeren op een W10 machine en dan na verplaatsen van de virtual disk herhalen op een server 2016 machine heeft wel kans van slagen.

Ik denk dat het een ongedocumenteerde "safety feature" is om te voorkomen dat inhoud op data volumes (die nog wel eens van de ene naar de andere VM / guest worden verhuisd) niet meer gelezen kan worden. Dit in tegenstelling tot systeemvolumes en omdat LZX compression dus eigenlijk bedoeld is als OS/Executable compression om eventuele datadichtheid op systeemvolumes te kunnen vergroten.
Onduidelijk is dan wel waarom een client OS als Windows 10 dat dan wel toestaat. Mogelijk voor compatibiliteit met dual-boot systemen of zo. Afijn, dat is speculatie. Als iemand het fijne ervan weet dan mag ie het zeggen :)

Al met al denk ik dat je de LZX compressie op niet ondersteunde systemen en voor zaken waarvoor MS het dus eigenlijk niet bedoelt of ondersteunt beter kunt laten.
Als ik het goed lees, zorgt de switch met /C en /EXE er ook voor dat directories niet gemarkeerd worden voor compressie dus bestanden die je na comprimeren toevoegt worden niet automatisch ook gecomprimeerd zoals met reguliere NTFS compressie wel gebeurt.
Dan zou je na iedere full backup of incrementele backup ook weer de extra bestanden moeten comprimeren. Kost een hoop CPU load en moeite en de vraag is of de totale winst in diskspace er allemaal tegen opweegt.
In je voorbeeld haal je 0,2 punten meer ratio. In mijn summiere tests haal ik iets vergelijkbaars.
Dus waarschijnlijk een winst van ergens tussen de 20% en 30%. Dat lijkt heel veel maar in plaats van 2TB opslaan neemt iets dus maar 1,7 TB in, en 17TB ipv 20, 170TB ipv 200. 1700 TB ipv 2000 TB. Nou nou..

En dat is na HEEL lang comprimeren welke compressie weer vervalt als je het verplaatst/kopieert, whatever..

Als het op deze manier echt substantieel verschil gaat maken, zijn er waarschijnlijk (kosten) efficiëntere en betere manieren om je backup te maken. Op deze manier betaal je straks die extra opslag via het stopcontact :+

Ik maak je niet voor gek uit, hoor. Je wilt weten waarom het niet werkt en daar heb ik niet eens een echt antwoord op gegeven maar ik probeer even het real-world scenario en use-case te begrijpen.

[ Voor 13% gewijzigd door akimosan op 08-05-2018 00:01 ]


  • Fairy
  • Registratie: Januari 2001
  • Niet online
Hee top dat je dat allemaal hebt uitgeprobeerd! Dank je wel. Wilde dit zelf ook al gaan proberen, maar dat is nu niet meer nodig :)

Voor mij maakt de compressietijd niet uit. De data is voor 99% statisch en het mooie is, als je de compact over de hele disk laat gaan slaat hij automatisch de al gecomprimeerde bestanden over, dus na een filesync kan ik de compact opnieuw draaien en is alles zo weer bijgewerkt.

Het gaat puur om een backup van mijn eigen nas. Deze data wil ik graag zo efficiënt mogelijk opslaan, zodat ik de vrijgekomen ruimte nog kan gebruiken voor wat temporary spul en wat ruimte om te experimenteren. Ik heb best wel wat data die goed gecomprimeerd kan worden.

Er zit al 4x 3TB in en een SSD van 250GB.

Als Windows 2016 dit niet support, dan ga ik misschien toch weer Windows 10 installeren. Ik heb er Server op staan, omdat ik beschik over een licentie, maar ik gebruik in principe geen Server functionaliteit op dit moment, maar was wel van plan om dit op termijn te gaan doen, om een beetje bij te blijven :)

  • Killah_Priest
  • Registratie: Augustus 2001
  • Laatst online: 28-11 13:26
Fairy schreef op dinsdag 8 mei 2018 @ 07:56:
Hee top dat je dat allemaal hebt uitgeprobeerd! Dank je wel. Wilde dit zelf ook al gaan proberen, maar dat is nu niet meer nodig :)

Voor mij maakt de compressietijd niet uit. De data is voor 99% statisch en het mooie is, als je de compact over de hele disk laat gaan slaat hij automatisch de al gecomprimeerde bestanden over, dus na een filesync kan ik de compact opnieuw draaien en is alles zo weer bijgewerkt.

Het gaat puur om een backup van mijn eigen nas. Deze data wil ik graag zo efficiënt mogelijk opslaan, zodat ik de vrijgekomen ruimte nog kan gebruiken voor wat temporary spul en wat ruimte om te experimenteren. Ik heb best wel wat data die goed gecomprimeerd kan worden.

Er zit al 4x 3TB in en een SSD van 250GB.

Als Windows 2016 dit niet support, dan ga ik misschien toch weer Windows 10 installeren. Ik heb er Server op staan, omdat ik beschik over een licentie, maar ik gebruik in principe geen Server functionaliteit op dit moment, maar was wel van plan om dit op termijn te gaan doen, om een beetje bij te blijven :)
Als het gaat om puur ruimte besparen : kun je dan niet beter gebruik maken van Dedup?

  • Fairy
  • Registratie: Januari 2001
  • Niet online
Ik heb alleen geen dubbele bestanden. Vraag me af of dat dan wel veel gaat uitmaken. Dedup gebruikt wel compressie, maar niet vergelijkbaar met LZX neem ik aan?

[ Voor 31% gewijzigd door Fairy op 08-05-2018 10:48 ]


  • DB LucF
  • Registratie: Februari 2008
  • Laatst online: 24-11 21:50
Probeer het uit d.m.v. ddpeval.exe.
Zelfs zonder dubbele bestanden haalde ik op onze fileserver over de 35% besparing op diskruimte. Het ligt natuurlijk helemaal aan de bestanden zelf hoeveel kleiner ze kunnen worden.
Pagina: 1