Client Side Caching Modes¶
BeeGFS clients provide two different file cache modes, settable using the client configuration option
buffered: uses a pool of small static buffers for write-back and read-ahead
native: uses the Linux kernel page-cache
buffered mode typically provides higher streaming throughput compared to the
cache mode. The
buffered mode will only cache a few hundred kilobytes of a file, while the
native mode is able to cache multiple gigabytes, dynamically adapting to the amount of available
native mode is work in progress and marked as experimental. If you enable it, be aware that
it could lead to problems.
buffered mode is the default cache type, and it is also the only valid cache type for clients
that are running on the same machine as a BeeGFS server daemon.
The cache type can be set in the client configuration file (
Note that BeeGFS servers also dynamically use available RAM for caching, independent of the client cache type.
Is it possible to use different caching types in different directories of the same file system?¶
Yes, it is. Usually, this is a common solution for
the problem when clients are configured to use the buffered caching mode by default, and special
applications that benefit from the more aggressive client-side caching of different cache types. You
could improve the startup time or runtime of such applications by setting
native on the client configuration file
However, consider that native cache is an experimental feature, and as such, has not been through full quality assurance. We are still working on it, and it should become a normal feature in a future release.
In case your tests reveal that this setting decreases the application runtime, please take the following steps to activate that cache type only on the directory from where the application is loaded, while keeping the rest of the system using the reliable cache type buffered. This reduces the risks of using this experimental feature.
Create a client config file (as a copy of the existing file
beegfs-config.conf) to contain the configuration of the second mount point (e.g.:
beegfs-config-native.conf). In this second configuration file, change the option
Create a directory to be the second mountpoint of BeeGFS (e.g.:
Add a new line to file
beegfs-mounts.confassociating the path of the newly created client configuration file to the second mountpoint path and configuring it to be readonly
(ro), as seen in the example below. Add
rwto the first line, to make explicit that that is a writable mountpoint, as follows.
/mnt/beegfs /etc/beegfs/beegfs-client.conf rw /mnt/private/beegfs_native /etc/beegfs/beegfs-client-native.conf ro
Restart the BeeGFS client service. At this point, you should have a second mountpoint (e.g.:
/mnt/private/beegfs_native) configured to use the native cache type. You could stop this procedure here and load the application from the second mountpoint. However, if you want to continue to use the same paths you used before, under the first mountpoint, take the next step.
Create a bind mount of the application directory on the second mountpoint to the directory on the first mountpoint. For example, lets consider you have the following paths: -
/mnt/beegfs- The main BeeGFS mountpoint. -
/mnt/private/beegfs_native- The readonly mountpoint using native cache. -
/mnt/private/beegfs_native/app- The directory that you want to mount at
/mnt/beegfs/appThen, you should allow only the root user to access the directory
/mnt/privateand execute the following command to create the bind mount:
$ mount -o bind,ro /mnt/private/beegfs_native/app /mnt/beegfs/app