[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