MemFS v2 û A Memory-based File System on HP-UX 11i v2

Also, note that the –r option is not supported. Since a read-only MemFS will always remain empty,
this option, applied to a MemFS, serves no purpose. Other HFS options such as behind, delayed,
fs_async, no_fs_async are not supported since they do not have any relevance in a Memory-based
File System context. MemFS does not support quotas.
The file-system specific option that MemFS supports is:
size – Specifies the maximum size to which this MemFS instance is allowed to grow.
A MemFS can also be automatically created at boot time by making an entry in fstab (4)
memfs directory memfs size=<size> 0 0 #comment
Since there is no backing device directly associated with MemFS, special is ignored, and it is
recommended that “memfs” is used as special field.
The umount (1m) syntax is:
/usr/sbin/umount [ -V ] directory
where directory is the mount point for the MemFS instance
Performance
A MemFS is expected to perform much better than a normal disk file system for smaller file and file
system sizes. As the memory occupied by MemFS increases to a level where swapping starts
happening, the performance may begin to taper off. If the swapping becomes excessive, performance
will decrease.
MemFS performance varies depending on usage and machine configurations. The benchmark tests
chosen to characterize the performance of MemFS are: Postmark, Connectathon basic tests and SDET.
Postmark Benchmark
Network Appliance’s Postmark is an appropriate benchmark to use for MemFS as it is an industry-
standard benchmark for small file and metadata-intensive workloads. It was designed to emulate
Internet applications such as e-mail, netnews, and e-commerce.
Postmark works by creating a configurable sized pool of random text files ranging in size between
configurable high and low bounds. These files are continually modified. The building of the file pool
allows for the production of statistics on small file creation performance. Transactions are then
performed on the pool. Each transaction consists of a pair of create/delete or read/append
operations. The use of randomization and the ability to parameterize the proportion of create/delete
to read/append operations are used to overcome the effects of caching in various parts of the system.
Test Configuration and Methodology
The system under test consisted of a HP rx7620 server comprising of 2 x 1600MHz Itanium CPUs,
32GB RAM. Postmark v1.5 was used.
The following graphs show the effects of applying increasing transaction loads to the various file
systems. Larger figures indicate higher performance.
The Postmark benchmark used the following parameters:
set size 10000 15000 (Sets the low and high bounds of files)
set number 10000 (Sets the number of simultaneous files)
set transactions RUN_LOAD (Sets the number of transactions)
set report verbose
set subdirectories 0 100
run