9.5
Table Of Contents
- Introduction
- System requirements
- Installation
- Using The Driver
- Mount options
- Additional Utilities
- Troubleshooting
- Troubleshooting processes
- Mount troubleshooting
- The install.sh script can’t find kernel sources
- Can’t compile the NTFS/HFS+ for Linux driver
- “Can’t load module” message at the end of installation
- ufsd module: kernel-module version mismatch
- ufsd module: create_module: operation is not permitted
- insmod: a module named as ufsd already exists
- insmod: Unknown symbol jnl_op (err0)
- Can’t mount NTFS/HFS+ volume
- Hardware issues
- Sysdump utility
- UFSD driver compatibility
- Frequently Asked Questions
- What are 'minor errors' reported by chkntfs utility?
- Warnings on Windows7/Vista when NTFS HDD is reconnected from Linux
- Recently changed file has its modification time a few hours ahead of or behind the current system time. Why?
- Why does mount option A make driver ignore mount option B?
- Does the driver have an optimization for avoiding data fragmentation?
- Why a lot of memory is used for volume mounting?
- Why the disk can't be dismounted?
User manual 40
(with its local time zone set to UTC+8), the file’s modification time will be reported 8 hours ahead of
current time (assuming that current time is the same on the Linux system and Windows PC).
There is ’bias’ mount option (see Mount options subsection) that allows to work around the issue
on systems that do not have time zone setting readable by C standard library (first introduced in
version 8.1.023). However, we recommend that time zone setting that can be used by C standard
library to convert time values, is added to the Linux system.
10.4 Why does mount option A make driver ignore mount option B?
When you mount disk with several mount options driver may ignore some of them.
This issue can happen when mount command is used with several options coded like:
# mount -t ufsd -o option_A,option_B -o option_C device mount point
In this case driver may ignore options A and B when mounting disk with option C.
To prevent this possibility it is recommended to write your commands with several options like:
# mount -t ufsd -o option_A,option_B,option_C device mount point
10.5 Does the driver have an optimization for avoiding data fragmentation?
We use the driver for recording video data. This writes a huge amount of small data packs to the hard
drive. Can you tell me if the driver has an optimization for avoiding data fragmentation? Or will this
cause a strong fragmentation to the hard disk?
As of UFSD version 8.4, level of fragmentation mostly depends on number of files that are written to a
volume simultaneously. In case only one file is written with small chunks of data, no fragmentation will
occur beyond fragmentation caused by fragmentation of free space already existing on the volume.
In case several files are written simultaneously, fragmentation will occur if no counter measures are
taken.
One of possible countermeasures is to allocate large continuous chunks of disk space for files, by
using:
fallocate (fd, FALLOC_FL_KEEP_SIZE, ...)
This routine allocates disk space for file, but does not change file size. Before closing the file, one
could call ftruncate() to reclaim disk space that was allocated but was not written to, but that is up
to developer to decide whether it is needed to reclaim the unwritten space (maybe the allocated space
will be used in future write sessions, e.g. as in P2P network client software when downloading large
files during several sessions). This approach also reduces CPU load thus improving performance, as
there’s no need for FS driver to invoke disk space allocation routines each time small block should be
appended to a file.
UFSD version 8.5 has transparent feature called delayed allocation (available on 2.6.X Kernel
versions with writeback_inodes_sb_if_idle routine, see delalloc mount option) to prevent frag-
mentation even in case writes are performed in small chunks. For this feature to work, the system
must have enough memory for disk/file cache and write operations must be performed in buffered
mode.
Paragon Technologie GmbH
Leo-Wohleb-Straße 8, 79098 Freiburg, Germany