TUNEFS(8) | MidnightBSD System Manager's Manual | TUNEFS(8) |
tunefs
— tune up
an existing UFS file system
tunefs |
[-A ] [-a
enable | disable ]
[-e maxbpg]
[-f avgfilesize]
[-j enable |
disable ] [-J
enable | disable ]
[-k
held-for-metadata-blocks]
[-L volname]
[-l enable |
disable ] [-m
minfree] [-N
enable | disable ]
[-n enable |
disable ] [-o
space | time ]
[-p ] [-s
avgfpdir] [-S
size] [-t
enable | disable ]
special | filesystem |
The tunefs
utility is designed to change
the dynamic parameters of a UFS file system which affect the layout
policies. The tunefs
utility cannot be run on an
active file system. To change an active file system, it must be downgraded
to read-only or unmounted.
The parameters which are to be changed are indicated by the flags given below:
-A
-a
enable
|
disable
-e
maxbpg-f
avgfilesize-j
enable
|
disable
Enabling journaling reduces the time spent by fsck_ffs(8) cleaning up a filesystem after a crash to a few seconds from minutes to hours. Without journaling, the time to recover after a crash is a function of the number of files in the filesystem and the size of the filesystem. With journaling, the time to recover after a crash is a function of the amount of activity in the filesystem in the minute before the crash. Journaled recovery time is usually only a few seconds and never exceeds a minute.
The drawback to using journaling is that the writes to its log adds an extra write load to the media containing the filesystem. Thus a write-intensive workload will have reduced throughput on a filesystem running with journaling.
Like all journaling filesystems, the journal recovery will
only fix issues known to the journal. Specifically if a media error
occurs, the journal will not know about it and hence will not fix it.
Thus when using journaling, it is still necessary to run a full fsck
every few months or after a filesystem panic to check for and fix any
errors brought on by media failure. A full fsck can be done by running a
background fsck on a live filesystem or by running with the
-f
flag on an unmounted filesystem. When running
fsck_ffs(8) in
background on a live filesystem the filesystem performance will be about
half of normal during the time that the background
fsck_ffs(8) is
running. Running a full fsck on a UFS filesystem is the equivalent of
running a scrub on a ZFS filesystem.
Presently it is not possible to take a snapshot on a UFS filesystem running with journaled soft updates. Thus it is not possible to reliably dump mounted filesystems or to run background fsck on filesystems enabled for journaling.
-J
enable
|
disable
-k
held-for-metadata-blocks-L
volname-l
enable
|
disable
-m
minfreeIf the value is raised above the current usage level, users will be unable to allocate files until enough files have been deleted to get under the higher threshold.
-N
enable
|
disable
-n
enable
|
disable
-o
space
|
time
-p
-s
avgfpdir-S
size-t
enable
|
disable
Note that this does not trim blocks that are already free. See
the fsck_ffs(8)
-E
flag.
At least one of these flags is required.
fs(5), dumpfs(8), gjournal(8), growfs(8), newfs(8)
M. McKusick, W. Joy, S. Leffler, and R. Fabry, A Fast File System for UNIX, ACM Transactions on Computer Systems 2, 3, pp 181-197, August 1984, (reprinted in the BSD System Manager's Manual, SMM:5).
The tunefs
utility appeared in
4.2BSD.
This utility does not work on active file systems. To change the root file system, the system must be rebooted after the file system is tuned.
You can tune a file system, but you cannot tune a fish.
August 16, 2022 | midnightbsd-3.1 |