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?
41 Paragon NTFS&HFS+ for Linux 9.5
10.6 Why a lot of memory is used for volume mounting?
Let us describe what’s going on when UFSD driver mounts volumes.
First of all, the driver must read file system boot record, and after verifying it, it must also read some
metadata from the mounted volume, namely, parts of $Mft and the entire $Bitmap metafile. For
example, if the volume has $Bitmap of 74 MB, the driver has to read not less than 74MB to mount
it. When our driver reads data from disk, Kernel keeps the data cached in memory. The amount of
memory that Kernel allocates for I/O buffers is printed in line #3 of /proc/meminfo file (Buffers:
XXXX kB). It’s up to Kernel to decide how much memory to allocate for I/O buffers (this can be
tuned via Kernel metafiles – please see the link below for more information). The memory (allocated
for ‘Buffers’) is normally reclaimed by kernel when Kernel or an application needs to allocate some
memory for ‘private’ use.
The real-time report on memory allocated by our driver for operations on specific partition that is cur-
rently mounted, is available in line #2 of file /proc/fs/ufsd/<block_device_name>/volinfo.
Peak amount of memory allocated by UFSD driver when mounting NTFS volume is around 250 KB.
The amount then reduced to 40 KB after mount operation is completed.
10.7 Why the disk can’t be dismounted?
When you try to dismount the disk with the ’umount’ command the volume is reported ’busy’ and can’t
be unmounted. Why?
This issue can happen when there are working processes, that are still using the volume. There-
fore, there are several options to remove the conditions that prevent the storage medium from being
unmounted:
1. Check if it is possible to safely unmount the storage using the system’s web interface.
2. Check if support for external storage can be disabled from the system’s web interface. Disable the
services and retry unmounting the storage medium.
3. Check if the various file/media sharing services (like multimedia, SAMBA (SMB), AFP, etc) can be
disabled from the system’s web interface. Disable the services and retry unmounting the storage
medium.
Note: Windows system keeps SAMBA connection to the storage for several minutes. Disable the
connection and retry to unmount the storage medium. For example in Windows XP it can be done from
’Disconnect network drive’ menu (e.g. ’My computer’ -> ’Tools’ -> ’Disconnect
Network Drive’ menu).
If the volume couldn’t be unmount with these steps, use ’sync’ command to flush buffers to the
storage medium before detaching it manually from the device:
# sync
It is recommended also to add ’sync’ command before ’umount’ to the unmounting web-interface
script, as it helps to avoid file system corruption on the storage medium, if unmount script was unsuc-
cessful and the drive was detached manually.
Copyright© 1994-2017 Paragon Technologie GmbH. All rights reserved.