[Eisfair] Platzbedarf von Dateien: Diskrepanz zwischen wahrer Größe und Belegung auf Datenträger

[Thomas Bork]

Am 20.12.2017 um 18:06 schrieb Jürgen Witt:

> debian # findmnt --target /public
> TARGET SOURCE            FSTYPE OPTIONS
> /      /dev/cciss/c0d0p3 ext4   rw,relatime,errors=remount-ro,data=ordered
> Und ein Auszug aus der Samba-Konfiguration:

Die Funktion:

do_strict_allocate ()
{
   if [ -z "$*" ]
   then
       checkmount='/'
   else
       checkmount="$*"

       if [ "$checkmount" = "%H" ]
       then
           checkmount='/home'
       fi
   fi

   findmnt_ext4_xfs=`findmnt --target "${checkmount}" | egrep ' ext4 | 
xfs '`
   if [ -n "${findmnt_ext4_xfs}" ]
   then
       echo " strict allocate = yes"
   fi
}

Diese Funktion kommt nicht in [global] sondern in den 
Freigabe-Definitionen (Beispiel [homes]: 'do_strict_allocate "%H"') zum 
Einsatz. Also sehe dort nach.

Um Euch nun vollends zu verwirren:

1.
Es gibt viele gute Gründe (Performance, Kompatibilität mit VHD-Dateien, 
reduzierte Fragmentierung), 'strict allocate = yes' zu setzen. Aufgrund 
der Intervention eines Users, bei dem es bei Verwendung von 
ext3-Dateisystemen zu Problemen kam, und weil empfohlen wird, die Option 
nur bei Dateisystem mit extends zu setzen, beschränke ich das Setzen 
dieser Option in Freigabe-Definitionen auf Dateisysteme mit extends. Das 
sind ext4 und xfs - ext3 gehört nicht dazu.

2.
Ist 'strict alocate = yes' gesetzt, scheint erst die Standard-Einstellung

allocation roundup size = 1048576

von Samba zu greifen, die bei Speicheranforderung von unter 1MB nach 
oben (eben 1MB) aufrundet. Bisher dachte ich eigentlich, diese Option 
würde immer greifen...

Man könnte nun also mit

allocation roundup size = 4096

experimentieren. Ich wette, dann wird wieder in 4kB-Blöcken alloziiert, 
was aber bei grösseren Dateien einen gewaltigen Teil des 
Performance-Schubes wieder auffrisst...

-- 
der tom
[eisfair-team]