[Eisfair_dev] sambaexpert: Überarbeitete neue Version 1.0.0

Thomas Bork tom at eisfair.org
So Jul 15 13:47:10 CEST 2018


Am 15.07.2018 um 13:01 schrieb Benjamin Heide:

> [global]
> strict allocate = no

Das ist der Default, siehe Ausgabe von

testparm -sv

Dort findest Du im global-Teil:

strict allocate = No

pvscsi # testparm -sv 2>/dev/null | grep allocate
         strict allocate = No
         strict allocate = Yes
         strict allocate = Yes
         strict allocate = Yes

Das erste Vorkommen von 'strict allocate' stammt aus dem global-Teil. 
Das wird hier bei mir in 3 Freigaben überschrieben, da ich als darunter 
liegendes Dateisystem ext4 verwende, welches extends unterstützt.

Aus den manpages:

strict allocate (S)

     This is a boolean that controls the handling of disk space 
allocation in the server. When this is set to yes the server will change 
from UNIX behaviour of not committing real disk storage blocks when a 
file is extended to the Windows behaviour of actually forcing the disk 
system to allocate real storage blocks when a file is created or 
extended to be a given size. In UNIX terminology this means that Samba 
will stop creating sparse files.

     This option is really designed for file systems that support fast 
allocation of large numbers of blocks such as extent-based file systems. 
On file systems that don't support extents (most notably ext3) this can 
make Samba slower. When you work with large files over >100MB on file 
systems without extents you may even run into problems with clients 
running into timeouts.

     When you have an extent based filesystem it's likely that we can 
make use of unwritten extents which allows Samba to allocate even large 
amounts of space very fast and you will not see any timeout problems 
caused by strict allocate. With strict allocate in use you will also get 
much better out of quota messages in case you use quotas. Another 
advantage of activating this setting is that it will help to reduce file 
fragmentation.

     To give you an idea on which filesystems this setting might 
currently be a good option for you: XFS, ext4, btrfs, ocfs2 on Linux and 
JFS2 on AIX support unwritten extents. On Filesystems that do not 
support it, preallocation is probably an expensive operation where you 
will see reduced performance and risk to let clients run into timeouts 
when creating large files. Examples are ext3, ZFS, HFS+ and most others, 
so be aware if you activate this setting on those filesystems.

     Default: strict allocate = no

>    dos filetimes = yes

Auch das ist der Default:

pvscsi # testparm -sv 2>/dev/null | grep filetimes
         dos filetimes = Yes

dos filetimes (S)

     Under DOS and Windows, if a user can write to a file they can 
change the timestamp on it. Under POSIX semantics, only the owner of the 
file or root may change the timestamp. By default, Samba emulates the 
DOS semantics and allows one to change the timestamp on a file if the 
user smbd is acting on behalf has write permissions. Due to changes in 
Microsoft Office 2000 and beyond, the default for this parameter has 
been changed from "no" to "yes" in Samba 3.0.14 and above. Microsoft 
Excel will display dialog box warnings about the file being changed by 
another user if this parameter is not set to "yes" and files are being 
shared between users.

     Default: dos filetimes = yes

>       veto files = /lost+found/  /.imapmail/  /.forward/  /.bash_history/
>   /.journal/  /.fetchids/  /.mailboxlist/  /.bash_logout/  /.ssh/
> /.archimap.log/  /.archimap-active/  /.archimap.log.backup/
> /.archimap-active.backup/

Diese Option mag zwar nützlich sein, bremst Deinen Server aber extrem 
aus, da alle Datei-Listen (und diese werden bei normalen Optionen sehr 
oft verwendet) nach diesen Zeichenketten gefiltert werden müssen.

-- 
der tom
[eisfair-team]


Mehr Informationen über die Mailingliste Eisfair_dev