Note: This web page was automatically created from a PalmOS "pedit32" memo.

QFS notes

These notes are an aggregate of:
1) What I got from some course notes a Sun trainer (Mary Ann Lynch -
thanks much!) let me use
2) Conversations on the sam-managers mailing list, which pertains to
both QFS and SAM-FS
3) Googling

BTW, Mary Ann now has a QFS web page:
- and you'll probably find it more coherent than this derivative.

Purchased by Sun from LSC Inc.

QFS generally used for SAN, but ESMF will have a NAS head on it

Extent based filesystem, like VxFS

This table is from a May, 1999 SunWorld:
filesystem|max filesystem size|max file size
SunOS 4.x|UFS|2 GB|2 GB
Solaris UFS|1 TB|2 GB
Solaris 2.6|UFS|1 TB|1 TB
VxFS|8,000 TB|8,000 TB
QFS|1 petabyte|1 PB

From a May, 1999 SunWorld (down to blank line) :
No ACL support?
Logging not used
Can do quick mount on reboot without fsck after crash
Cannot grow or shrink?
The QFS filesystem from LSC provides integrated volume management and
allows striping and concatenation of files within the filesystem. The
filesystem is configured on multiple devices, rather than the traditional
single device. Each file within the filesystem may be concatenated or
striped with different interlace sizes, on a file-by-file basis.
No locking snapshots?
No Quotas?!?!
HSM capable

See also "SAM-FS notes"

From a March 2004 "technical overview" document from Sun:
- To provide more optimized throughput and scalability, QFS software
limits the movement of
the physical head on the disk with new technologies such as metadata
separation, variable block
size, pre-allocation, and automatic direct I/O. Additionally, integrated
volume management with
performance options such as disk striping and disk allocation eliminate
additional software layers
and uses less system and CPU overhead than other UNIX file systems,
while improving
performance and scalability.
- uses variable block sizes (from 4k and up) to optimize storage of
files of a variety of sizes
- Uses dynamic inode creation, for fast filesystem creation (no inode
preallocation to wait for) and to allow a practically unlimited number
of files.  Growing a filesystem is also supposed to be very fast for
this reason.
- Can create a "stripe group" AKA a "stripe of stripes".
- Volume management and filesystem are combined into a single software
layer for performance - IE you do not create a large metadevice and then
mkfs that - you create the filesystem on multiple devices.
- All -completed- transactions are recoverable in the event of a system crash
- Q-Write is some sort of concurrency facility that requires turning
off posix locking
- For small files in QFS "paged I/O" is faster for lots of small files,
while "directio" is faster for large files ("forceddirectio" mount
option or can be set on files or directories.  If set on a directory,
files within that directory inherit the behavior).  Switching between
paged I/O and direct I/O can also be set to switch automatically,
depending on the sizes of reads, writes, or both.
- Applications over QFS can preallocate sequential disk blocks to optimize
large disk writes
- QFS is "multi-reader", allowing it to be directly mounted on multiple
systems simultaneously.  However, one system is a writer, and all others
are readers.  If the writer dies, one of the readers is selected to become
the writer.  There is no locking between the writer and the readers.
- QFS has ACL's
- QFS Metadata Server, AKA "QMS" enables multiple Solaris hosts to
both read and write to a given file in a filesystem.  There should
be one QMS for each filesystem.  Each shared file system must have a
QMS to provide essential file allocation and file locking services to
all hosts mounting the share file system, and to make sure all access
is coordinated and secure. Only one QMS server can be active at any
one time. The QMS communicates with the other hosts via a TCP socket,
taking advantage of optimized communications protocols and leaving the
Fibre Channel free to actually transfer data.
- QMS handles access to files with "leases", for reading, writing or
appending.  Only one process can append at a time.  Default duration of
a lease is 30 seconds.
- With multiple writers to the same file (via leases), no buffer cache is
used - writes go directly to disk, to avoid cache coherency complications
- Entire filesystem locking semantics are consistent with NFS
- For redundancy, multiple QMS's can be configured for a given filesystem,
but only one will be active at a time.  The alternate QMS is activated
with samsharefs
- QFS can grant heterogeneous hosts (not all solaris) SAN access to the
data, using SANergy.  The SANergy Meta-Data Controller (MDC) is configured
on the QMS.  SANergy client must be installed on the heterogenous clients
- SANergy can also be combined with SAM-FS
- QFS supports quotas for users, groups or administration sets, per mount point

- What does "QFS" stand for?
- What does "SAM-FS" stand for?
- What is the name of the filesystem that is common to QFS and SAM-FS?
- Are quotas still not supported (or is SAM-FS required for that) - one
document says yes, another no?  Are the extended quota features of SAM-FS
(?) available via NFS (in SAM-FS notes too)
- Can you or can you not grow a QFS filesystem?  Is SAM-FS required
for that?  I found two documents, one said yes, one said no
- What is Q-Write (some sort of file concurrent access thing)?
- How does one set up automatic paged vs direct I/O?
- How does an application writing to QFS request sequential preallocation
of disk blocks?
- Does QFS have ACL's or not?  One article said yes, another said no
- Are we getting redundant QMS'?

From sam-managers on growing and shrinking: My actual point of knowledge is NO. If you want to shrink your filesystem you have to backup your filesystem, to destroy it and ro rebuild it. (samfsdump; newfs; samfsrestore) (qfsdump; newfs; qfsrestore) /\/\/\/\/\/\/\/\ You can reconstitute the filesystem after reconfiguring the /etc/opt/{SUNWsamfs,LSCsamfs}/mcf file and use the /opt/{SUNWsamfs,LSCsamfs}/sbin/samgrowfs -f mcf-family-name to grow a filesystem. Under 4.x I think you'd also need to pkill -HUP sam-fsd (as root), but I haven't worked on 4.x all that much. To shrink one is probably best done as described Markus, by using the samfsdump and samfsrestore utilities to set up the directory structure, though on a standalone QFS installation this will take much more space because you'd want to include the data with the samfsdump.
From sam-managers: Yes, QFS4 supports ACL's. Be aware however, that not all applications are ACL-proof.
From sam-managers: Quotas are supported in QFS (and in one of the newer versions also in SAM-FS, I think). Unfortunately, the Solaris rquotad does not support samfs filesystems.
From sam-managers: it depends on whether you are using shared QFS or standalone QFS: per sun ... "I would not recommend using ACLs with shared QFS. ACLs function pretty much as exepected on standalone QFS but not shared. I would not recommend using ACLs with shared QFS until the 4.4 release."
Sun doc about QFS:
2005-09-07 I'm hearing that QFS has restrictions on how it can be grown. Specifically, word on the sam-managers mailing list is that: If you have a QFS of 2 RAID 5's, and you add a disk to one of the RAID 5's, even if you can grow the RAID 5, you cannot grow QFS this way. However, if you have, say, 3 disks to make another RAID 5, then you can add that new RAID 5 to the mcf and grow QFS with that.
2005-09-07 Quotas: I'm hearing that although QFS does support some advanced quota functionality, it is not avaialble via rquotad, and hence is not available via the usual "quota -v". Sun doc on quotas with QFS:
The mcf I settled on: # Equipment Eq Eq Family Device Addl # Identifier Ord Type Set State Params #------------ --- ---- --- ----- ------ qfs1 10 ma qfs1 /dev/dsk/c3t42d8s4 11 mm qfs1 /dev/dsk/c3t42d0s2 12 mr qfs1 /dev/dsk/c3t42d1s2 13 mr qfs1 /dev/dsk/c3t42d2s2 14 mr qfs1 /dev/dsk/c3t42d3s2 15 mr qfs1 /dev/dsk/c3t42d4s2 16 mr qfs1 /dev/dsk/c3t42d5s2 17 mr qfs1 /dev/dsk/c3t42d6s2 18 mr qfs1 /dev/dsk/c3t42d7s2 19 mr qfs1 /dev/dsk/c3t42d8s5 20 mr qfs1 #Section 2. Storage Identification - but we have nothing to add # Standalone Tape Drive Identification

Back to Dan's palm memos