Chapter 12: SmartFiles — Files, Objects, and Unstructured Data Services

For most enterprises, the largest pool of "data sprawl" is unstructured. Cohesity SmartFiles is the product that turns the same DataPlatform you already use as a backup target into a primary, multi-protocol unstructured-data service. SmartFiles is not a separate appliance to learn — it is a consumption mode of the cluster you have already designed.

1. SmartFiles Architecture

From SpanFS to View: One File System, Many Faces

SmartFiles is not a separate product riding on top of Cohesity — it is a way of consuming SpanFS, the same distributed file system that holds backup snapshots, archived databases, and replicated VMs. SpanFS exposes a single global namespace across every node in the cluster with strict consistency. That single-namespace property is what lets the same logical object be a file to an NFS client, a share to an SMB client, and an object to an S3 client at the same time, without copying data into protocol-specific silos.

The central SmartFiles construct is the View. A View is a logical container that lives inside a View Box (Storage Domain) and that can be exposed simultaneously as:

• An NFS export, with mount-point / volume semantics (NFSv3 and NFSv4 are both supported).
• An SMB share, with Windows file share semantics (SMB3 with signing and encryption).
• An S3 bucket, where files become S3 objects keyed by their path in the View.

View Boxes / Storage Domains: The Policy Boundary

The View Box — which newer documentation calls a Storage Domain — is the policy container for the Views inside it. The View Box is where you define storage efficiency, resiliency (RF2/RF3 or erasure coding), encryption, tiering policy, and default quotas. A common architectural pattern is to maintain at least two Storage Domains: one tuned for backup landing (high dedupe, erasure-coded, HDD-biased) and one tuned for primary file/object workloads (SSD-biased, lower dedupe ratio target) so that backup ingest cannot starve a busy SmartFiles user share.

+--------------------------------------------------------------+
| Cohesity Cluster (SpanFS, single global namespace)           |
|                                                              |
|  +----------------------+    +-------------------------+     |
|  | Storage Domain:      |    | Storage Domain:         |     |
|  | "BackupTarget"       |    | "SmartFiles-Primary"    |     |
|  | RF2 + EC 4:2         |    | RF2, SSD-biased         |     |
|  | Inline dedupe        |    | Post-process dedupe     |     |
|  |                      |    |                         |     |
|  |  View: vmware-bk     |    |  View: media-projects   |     |
|  |  View: oracle-bk     |    |  View: build-artifacts  |     |
|  |  View: m365-bk       |    |  View: home-dirs        |     |
|  +----------------------+    +-------------------------+     |
+--------------------------------------------------------------+

Protocol Surface: SMB3, NFSv3/v4, S3

Cross-Protocol Identity and Locking

• NFS uses UID/GID (and in NFSv4, name@domain principals).
• SMB3 uses Windows SIDs and Kerberos principals.
• S3 uses bucket policies and IAM-style access keys.

Cohesity bridges these via AD/LDAP integration. Cross-protocol locking is enforced inside SpanFS: an SMB3 oplock blocks conflicting NFS access per the locking semantics SpanFS exposes.

2. Quotas, QoS, and Tiering

Quotas: Capacity Governance

SmartFiles supports both per-View quotas and per-user quotas inside a View, with audit logs of usage and Helios REST endpoints (getViewUserQuotas) to drive reporting and chargeback. Storage-Domain defaults are typically configured via the CLI parameters default-view-quota (in GiB) and default-view-quota-alert-limit.

A subtlety the CCAE exam can test: Cohesity does not sharply distinguish "soft" from "hard" quotas in the NetApp sense. Instead, think of:

• The quota itself as the enforced cap.
• The alert-limit as the soft trigger — the value at which an operator gets a warning.

QoS Policies: Workload-Aware Placement

Two CCAE design rules: (1) Pick the QoS at View creation — changing it on a busy View is non-trivial and may require data movement. (2) Match QoS to workload, not to who paid for it. Putting an active SMB user share on "Backup Target Low" tanks latency; putting a backup target on "TestAndDev High" wastes SSD.

Tiering: Hot/Cold Placement

SmartFiles applies policy-driven tiering across SSD, HDD, and S3-compatible cloud targets. Cold blocks move out without breaking the namespace — clients still see the file or object at the same path, and access triggers a transparent recall. Tiering is configured at the Storage Domain or View level and applies to all protocols simultaneously: a file tiered to S3 that is then read via SMB or NFS or the S3 API behaves identically.

Architects should explicitly model:

• Recall latency — first read after tier-down hits cloud egress latency.
• Working set sizing — local SSD/HDD must still hold the active working set.
• Egress cost — repeated recalls of the same dataset can dwarf the storage savings.

Worked Example: Media-and-Entertainment Workflow

Storage Domain: "Media-Primary"  (SSD-biased, RF2, post-process dedupe)
  +-- View: "edit-projects"
  |     Protocols: SMB3 R/W, NFSv4 R/W, S3 read-only
  |     QoS: TestAndDev High (SSD priority, low latency)
  |     Quota: 50 TB, alert 40 TB
  |     Tiering: cold > 90 days idle -> S3 (Standard-IA)
  |
  +-- View: "render-scratch"
        Protocols: NFSv4 R/W, S3 R/W
        QoS: General-purpose (HDD, throughput)
        Quota: 200 TB, alert 160 TB
        Tiering: cold > 30 days idle -> S3 (Glacier IR)

3. Data Protection for SmartFiles

Snapshots and Policies

Every View can be snapshotted on a schedule using the same Protection Policies covered in Chapter 7 — frequency, hierarchical retention (daily / weekly / monthly / yearly), and lock attributes. SnapTree gives near-zero overhead for snapshots, so retention windows can be aggressive without paying capacity penalties. Snapshots are mountable as read-only Views, which makes "previous versions" workflows straightforward for SMB users.

For ransomware resilience, combine snapshot policies with DataLock (Chapter 11) so snapshot deletes require either time-elapse or quorum approval.

DR Replication for SmartFiles

Views replicate to a remote cluster using the same replication engine that DataProtect uses. Architectural notes:

• AD/LDAP must be reachable from the DR site for SMB and NFSv4 access to resolve identities post-failover.
• DNS / VIP planning matters more than for backup workloads — clients connect on protocol VIPs.
• S3 endpoint URLs must be planned end-to-end; cloud-native applications often hard-code bucket endpoints.

File Audit Logging

SmartFiles ships native file audit logging that records per-event activity (open, read, write, rename, delete, ACL change) on Views. This is pushed to Syslog or to SIEM platforms and replaces bolt-on third-party audit appliances. Audit logging is also a control for ransomware detection: an unusual rate of rename-then-delete on a user share is a classic encryption signature.

Anti-Virus and ICAP Integration

SmartFiles integrates antivirus scanning natively via the ICAP (Internet Content Adaptation Protocol). When ICAP AV is enabled on a View, write paths fan out to one or more configured ICAP servers (Trellix, Symantec, Sophos) for scanning before the data is committed.

For the CCAE exam, remember:

• ICAP is a synchronous scan; size scanner pools accordingly or scope ICAP to specific Views (e.g., user shares but not render scratch).
• ICAP scan results integrate with audit logs and DataHawk where deployed.
• Cohesity's ICAP support is a feature of SmartFiles itself; it is not an additional appliance.

4. Migration and Modernization

Three Migration Paths

1. NAS File Migration Service — packaged Professional Services engagement covering cluster prep, planning, cutover, and end-state docs, sized at ~30 TB per migration event. For larger estates, plan multiple cutover events.
2. Transparent cold-data tiering — SmartFiles scans the source NAS, classifies data by access pattern, and policy-tiers cold blocks to Cohesity (or cloud) without rehydration on access. The legacy NAS keeps serving hot data; SmartFiles silently absorbs the cold tail.
3. Backup-driven cross-filer restore — back up the source NAS to Cohesity, then restore directly into a SmartFiles View (or even into a different NAS array). Especially useful when SMB/NFS permission preservation matters.

Cohesity SmartFiles vs. NetApp ONTAP and Dell PowerScale (Isilon)

Lift-and-Shift Sequence

1. Discovery. Run SmartFiles analytics against source filers; produce hot/warm/cold map per share.
2. Decision tree. Per share: tier-off vs. full cutover vs. backup-driven restore.
3. Identity and AV. Stand up AD/LDAP and ICAP scanner pools before any cutover.
4. QoS placement. Map each share to a QoS class up front.
5. Cutover windows. Plan at the 30-TB-per-event sizing; use replication seeding to minimize cutover time.
6. Decommission. Retire source filer once SmartFiles View is authoritative and snapshots have aged.