EMC 6EMC SFSVery little is known about the Symmetrix File System largely known as SFS. Symmetrix File System is an EMC IP and practically only used within the Symmetrix environment for housekeeping, security, access control, stats collection, performance data, algorithm selection, etc.If there are any facts about SFS that are known to you, please feel free to leave a comment. This post talks about the effects of SFS and not really the underlying file system architecture.Some facts about the Symmetrix File System are highlighted below.Symmetrix File System (SFS) resides on volumes that have specially been created for this purpose on the Symmetrix SFS volumes are created during the initial Enginuity Operating Environment load (Initial install) 4 Volumes (2 Mirrored Pairs) are created during this process SFS volumes were introduced with Symmetrix Series 8000, Enginuity 5567 and 5568 Characteristics4 SFS volumes are spread across multiple Disk Directors (Backend Ports) for redundancy SFS volumes are considered as reserved space and not available to use by the host Symmetrix 8000 Series: 4 SFS volumes, 3GB each (cylinder size 6140). Reserved space is 3GB x 4 vols = 12 GB total Symmetrix DMX/DMX-2: 4 SFS volumes, 3GB each (cylinder size 6140). Reserved space is 3GB x 4 vols = 12 GB total Symmetrix DMX-3/DMX-4: 4 SFS volumes, 6GB each (cylinder size 6140). Reserved space is 6GB x 4 vols = 24 GB total, (Its different how the GB is calculated based on cylinder size on a DMX/DMX-2 vs a DMX-3/DMX-4) Symmetrix V-Max: 4 SFS volumes, 16GB each, Reserved space is 16GB x 4 vols = 64GB total SFS volumes cannot reside on EFD (Enterprise Flash Drives) SFS volumes cannot be moved using FAST v1 and/or FAST v2 SFS volumes cannot be moved using Symmetrix Optimizer SFS volumes cannot reside on Vault Drives or Save Volumes SFS volumes are specific to a Symmetrix (Serial Number) and do not need migration SFS volumes are managed through Disk Directors (Backend Ports) only SFS volumes cannot be mapped to Fiber Directors (now FE Frontend Ports) EffectsSFS volumes are write enabled but can only be interfaced and managed through the Disk directors (Backend Ports). SFS volumes can go write disabled, which could cause issues around VCMDB. VCMDB issues can cause host path (HBA) and disk access issues. SFS volume corruption can cause hosts to lose access to disk volumes. If SFS volumes get un-mounted on a Fiber Director (Frontend Port), can result into DU (Data Unavailable) situations. FixesSince the SFS volumes are only interfaced through the Disk Directors (Backend Ports), the PSE lab will need to be involved in fixing any issues. SFS volumes can be VTOCed (formatted) and some key information below will need to be restored upon completion. Again this function can only be performed by PSE lab. SFS volumes can be formatted while the Symmetrix is running, but in a SCSI-3 PGR reservation environment it will cause a cluster outage and/or a split brain. No Symmetrix software (Timefinder, SYMCLI, ECC, etc) will be able to interface the system while the SFS volumes are being formatted. The security auditing / access control feature is disabled during the format of SFS volumes, causing any Symmetrix internal or external software to stop functioning. Access Control Database and SRDF host components / group settings will need to be restored after the SFS format Access / Use caseAny BIN file changes to map SFS volumes to host will fail. SFS volumes cannot be managed through SYMCLI or the Service Processor without PSE help. SYMAPI (infrastructure) works along with SYMMWIN and SFS volumes to obtain locks, etc during any SYMCLI / SYMMWIN / ECC activity (eg. Bin Changes). Since FAST v1 and FAST v2 reside as a policy engine outside the Symmetrix, it uses the underlying SFS volumes for changes (locks, etc). Performance data relating to FAST would be collected within the SFS volumes, which FAST policy engine uses to gauge performance. Performance data relating to Symmetrix Optimizer would be collected within the SFS volumes, which Optimizer uses to gauge performance. Other performance data collected for the DMSP (Dynamic Mirror Service Policy). All Audit logs, security logs, access control database, ACLs etc is all stored within the SFS volumes. All SYMCLI, SYMAPI, Solutions enabler, host, interface, devices, access control related data is gathered on the SFS volumes. With the DMX-4 and the V-Max, all service process access, service processor initiated actions, denied attempts; RSA logs, etc are all stored on SFS volumes. UnknownsSFS structure is unknown SFS architecture is unknown SFS garbage collection and discard policy is unknown SFS records stored, indexing, etc is unknown SFS inode structures, function calls, security settings, etc is unknown As more information gets available, I will try to update this post. Hope this is useful with your research on SFS volumes