XFS + NFS ruimte reservering ?

[DDX]

Server (centos 6.2) met xfs filesystem die via nfs geshared wordt.

Maak ik een 10gigabyte test file aan over nfs :

code:

dd if=/dev/zero of=10Gtest bs=1M count=10000      
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 74.827 s, 140 MB/s

output van ls en du ( ls -al ; du) :

code:

-rw-r--r-- 1 root root 429170688 Jun  8 10:13 10Gtest
654456  10Gtest

-rw-r--r-- 1 root root 1756831744 Jun  8 10:13 10Gtest
2230720 10Gtest

-rw-r--r--   1 root root 2492145664 Jun  8 10:11 10Gtest
4348288 10Gtest

-rw-r--r--   1 root root 4686782464 Jun  8 10:11 10Gtest
8542592 10Gtest

-rw-r--r-- 1 root root 10485760000 Jun  8 10:12 10Gtest
16943552        10Gtest

Er wordt dus ruimte gereserveerd oid voor de file.
En op het moment dat de file 10 gigabyte is, heb je een verspilling van bijna 7 gigabyte.
(ook df laat zien dat deze ruimte echt ingenomen wordt)

Doe ik dezelfde test op een ext4 filesystem (zelfde export en mount opties voor nfs) dan wordt er niets gereserveerd en is een 10 gigabyte file ook echt 10 gigabyte.

En lokaal een file van 10gigabyte op het xfs filesystem aanmaken heeft ook nergens last van.

Unmount ik het xfs filesystem en mount ik hem weer is de reservering ook direct opgeheven en neemt de file 10gigabyte in.
Een defrag starten (xfs_fsr) lost het probleem niet op.
Misschien dat het na enige tijd vanzelf ook opgelost wordt, maar iig niet binnen 1 dag.

[slommer]

Hier ook ff getest:

code:

# ls -la ; du
-rw-r--r-- 1 nfsnobody nfsnobody 162529280 Jun  8 11:08 test.bin
262144  .

oudere files hebben het probleem niet (meer?)

[Spider.007]

Wat je bedoelt met het "verspillen van 7 GiB" snap ik niet, maar loop je niet gewoon tegen de Delayed allocation feature van XFS aan?

[DDX]

Omdat een file die 10gigabyte is, daadwerkelijk 16,2 gigabyte inneemt.
Lijkt me prima om iets meer ruimte te gaan innemen als ik files aanmaak, maar bijna het dubbele ?

Kwam er achter doordat ik aantal opnames op m'n dreambox had gemaakt naar de nfs share. (files van ieder zo rond de 10gigabyte) en veel meer ruimte kwijt was dan in verwacht had.

En wanneer wordt deze ruimte dan ooit weer vrijgegeven, zonder dat ik disk opnieuw moet mounten ? (iig niet met defrag of gewoon dag wachten)

[slommer]

iemand nog een idee?

[Mijzelf]

iemand nog een idee?

Weet je zeker dat het een probleem is? Ik neem aan dat dit verschijnsel te maken heeft met pre-allocatie. De manier die je gebruikt om de file aan te maken geeft het filesysteem geen enkele indicatie hoe groot de file kan worden, en dus wordt er wat extra ruimte gereserveerd om toekomstige groei op te vangen zonder dat fragmentatie nodig wordt.

Maar als dat zo is verwacht ik dat het filesysteem de ruimte onmiddelijk vrij geeft als het ergens anders voor nodig is, en is er dus feitelijk geen probleem.

[DDX]

Van het linkje van Spider.007 :

The actual block allocation occurs only when the data is finally flushed to disk.

Dat zou na aantal dagen toch wel gebeurd moeten zijn lijkt me ? (eerder aantal minuten max)

Ik heb afgelopen weekend zo'n 6 opnames gemaakt en ben daardoor dus zo'n 60 gigabyte 'kwijt'.
Dit soort effecten dus :

code:

]$ ls -alh 20120610\ 2017\ -\ NED2\ HD\ -\ KRO\ Detectivemaand_\ Liza\ Marklund.ts  
-rw-r--r-- 1 root root 4.3G Jun 10 21:55 20120610 2017 - NED2 HD - KRO Detectivemaand_ Liza Marklund.ts

]$ du -hs 20120610\ 2017\ -\ NED2\ HD\ -\ KRO\ Detectivemaand_\ Liza\ Marklund.ts
8.1G    20120610 2017 - NED2 HD - KRO Detectivemaand_ Liza Marklund.ts

Mogelijk dat dit vrijgegeven wordt als vrije ruimte op 0 komt, maar lijkt me dat dit toch veel eerder vrij gegeven zou moeten worden ?
En om nou iedere week te gaan rebooten (want het wordt dus opgelost bij umount/mount)

Aanvulling: redhat 5.8 met xfs en nfs heeft geen last van dit probleem.

[ Voor 4% gewijzigd door DDX op 11-06-2012 11:12 ]

[DDX]

Heb vandaag eindelijk de oorzaak gevonden :

http://serverfault.com/qu...e-and-full-of-sparse-file