--- title: "Concepts" slug: "dev-datastore-concepts-index" updated: 2026-10-30T18:19:06Z published: 2026-10-30T18:19:06Z canonical: "docs.vastdata.com/dev-datastore-concepts-index" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Concepts *Applies to VAST Cluster 5.5.* Read this before you design an application on VAST S3 or NFS. It explains what a bucket is on a VAST cluster, how object keys relate to file paths, who the cluster thinks you are, what decides whether a request is allowed, and what happens to your data after you write it. ## Views, buckets and exports A VAST cluster keeps all its data in one namespace of directories and files. A **view** exposes one path in that namespace to clients, with one or more protocols: | Protocol on the view | What clients see | | --- | --- | | NFSv3, NFSv4 | An export you mount. NFSv4 views can be mounted as NFSv4.1 or NFSv4.2. | | SMB | A share. | | S3 Bucket | A bucket. The view's path is the bucket's root. | | S3 Endpoint | Not a bucket: a template. Buckets that users create with the S3 API (`CreateBucket`) become new views under its path. | | Database, Kafka | VAST DataBase and VAST Event Broker. See [VAST DataBase](/develop/docs/dev-database-overview) and [VAST Event Broker](/develop/docs/dev-event-broker-overview). | A view with S3 Bucket and NFS is one directory tree that is both a bucket and an export. That's what makes [multiprotocol access](/develop/docs/dev-datastore-guides-multiprotocol) possible. Each view has a **view policy**. It holds the host rules (which client addresses may use which protocol, read-write or read-only), the **security flavor** (below) and protocol-specific settings. Views and view policies are set up by your platform team (KB: [Views and View Policies](/docs-5-5/docs/views-and-view-policies)). Rules that affect how you design: - **Bucket names are unique across the cluster,** across all tenants. NFS aliases and SMB share names only need to be unique in a tenant. - **A bucket can't be renamed or moved** after it's created. - **Buckets don't nest.** A view with an S3 bucket can't have other views under it or on the same path. - **You may be able to create buckets yourself.** If your platform team has set up an S3 Endpoint view that names you (or your group) as a bucket creator, `CreateBucket` creates a new view under that path. Otherwise buckets are created for you as views. ## Tenants A cluster can be divided into **tenants**. Each tenant has its own part of the namespace, its own users and its own virtual IP pools (or shares pools with others). An S3 access key pair works in one tenant only. Two tenants can each have a directory `/data`, but not each a bucket `data`. ## Keys and paths An S3 object key in a bucket is a path relative to the bucket's view path. A file that an NFS client writes at `src/component` under the export is the object with key `src/component` in the bucket on the same view, and the other way round. Because S3 keys are just names and file paths are a tree, some keys have no file equivalent: - Keys can start or end with `/` and can contain `//`. Objects with such keys exist only for S3: NFS and SMB clients can't see them as files or directories. - Keys with path parts like `./`, `../`, `/./` or `/../` are refused unless the view policy allows them ("S3 special chars support"). - A key ending in `/` is an ordinary object that S3 tools often use as a directory marker. - `a/b` and `a/b/` can both exist, but you can't have an object `key1` and also an object `key1/key2`: `key1` can't be a file and a directory at once. Details and the versioned-bucket rule are in [multiprotocol access](/develop/docs/dev-datastore-guides-multiprotocol#keys-that-have-no-file). ## Who the cluster thinks you are Every signed S3 request carries an access key, and every access key belongs to one **VAST user** in one tenant. The user can be a local user or come from a provider such as Active Directory or LDAP, so the same person or service account can also own files over NFS (by UID) and SMB (by SID). The cluster stores permissions in a protocol-independent form and checks them against all of a user's identities. Requests without a signature are **anonymous**. Anonymous access is off by default and is allowed per bucket by your platform team. Applications can also use **temporary credentials** from the cluster's Security Token Service, by assuming an IAM role. Requests made with them are checked against the role's policies, not the user's. See [access](/develop/docs/dev-datastore-operations-access#temporary-credentials). ## What decides whether a request is allowed ![A view policy's security flavor decides how requests on a multiprotocol view are checked. S3 Native: S3 requests are checked against identity and bucket policies, then S3 ACLs, and NFS calls that map to S3 actions are checked against the policies too; chmod and chown over NFS are ignored. NFS: requests from every protocol are checked against the files' mode bits and POSIX or NFSv4 ACLs, and identity and bucket policies are ignored. SMB: SMB (NTFS) ACLs, policies ignored. Mixed Last Wins: ACLs that any protocol can change, the last change wins, policies ignored. Ask your platform team which flavor your view uses.](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/ds-security-flavors.svg?sv=2026-02-06&spr=https&st=2026-11-08T08%3A55%3A20Z&se=2026-11-08T09%3A55%3A20Z&sr=c&sp=r&sig=%2BU9AmzpitjczBpiEpwmYjJnL%2BJ9FFb016FETUQMAgTA%3D) *The view's security flavor decides whose permissions apply.* The view policy's **security flavor** decides whose permission rules apply to every protocol on the view: | Flavor | Permission checks follow | Identity and bucket policies | Who can set permissions | | --- | --- | --- | --- | | S3 Native | S3: policies first, then S3 ACLs | Apply, to S3 and to the NFS and SMB requests that map to S3 actions | S3 clients only | | NFS | NFS mode bits (and POSIX ACLs) | Ignored | NFS clients only | | SMB | SMB (NTFS) ACLs | Ignored | SMB clients only | | Mixed Last Wins | Similar to SMB | Ignored | All protocols | So an identity policy that allows `s3:GetObject` has no effect on a bucket whose view uses the NFS flavor: there, S3 reads are checked against the files' mode bits. Ask your platform team which flavor your view uses. A view with an S3 bucket can't change flavor after it's created. What each flavor means for the same data over S3 and NFS, with examples, is in [multiprotocol access](/develop/docs/dev-datastore-guides-multiprotocol#ownership-and-permissions). ## What happens when you write A write lands first in the cluster's **write buffer**, fast storage-class memory in its storage enclosures, and the cluster later moves it to flash. It reduces the data on the way: duplicate blocks are stored once, and the rest is compressed or stored as its difference from similar data elsewhere on the cluster. Reduction happens after the write, so it doesn't make writes slower ([Data reduction](/docs-5-5/docs/data-reduction)). How this works for every service is in [the cluster underneath](/develop/docs/dev-database-concepts-architecture-cluster-architecture#data-reduction). For an application: - **Send data uncompressed and unencrypted if you want the cluster to save space.** Encrypted data hardly reduces, and data you've compressed yourself reduces much less ([whitepaper](https://www.vastdata.com/whitepaper)). Compress on the client only when the network, not capacity, is your limit. - **Capacity has two numbers.** *Logical* capacity is what you wrote; *usable* capacity is what it takes after reduction. Ask your platform team which one your quota counts. ## Snapshots Your platform team can take **snapshots** of a path, on a schedule or on demand. A snapshot is a read-only copy of the path's directories, files and objects at one moment. It copies nothing when it's taken: it holds on to data that would otherwise be released when you delete or overwrite it, so a snapshot of data that changes a lot takes more space over time ([Snapshots](/docs-5-5/docs/snapshots)). Over NFS and SMB you can read a snapshot in the hidden, read-only `.snapshot` directory of the snapshotted directory: a snapshot `daily` of `/a/b` is at `/a/b/.snapshot/daily`. A view policy can also make `.snapshot` appear in every subdirectory. Use it to recover a file you deleted or to read a consistent copy while the live data changes. Snapshots of the same path can also be copied to other clusters by replication; see [the cluster underneath](/develop/docs/dev-database-concepts-architecture-cluster-architecture#copies-on-other-clusters). ## Quotas and quality of service Two cluster settings can stop or slow your application without anything being wrong with it. Your platform team sets both. **Quotas** limit a directory, or a user or group in it: how much capacity it can use, and how many files, directories or objects it can hold. A quota covers everything under the directory, whatever the protocol ([Overview of quotas](/docs-5-5/docs/overview-of-quotas)). - At the **soft limit**, writes still work, and an alarm is raised. If the soft limit stays exceeded for the whole grace period, writes are blocked. - At the **hard limit**, writes are blocked. - With quotas on nested directories, the most restrictive one applies. **Quality-of-service (QoS) policies** cap bandwidth or I/O operations per second (IOPS) for a view or for a user, for reads, writes or both, over NFS, SMB and S3 ([QoS overview](/docs-5-5/docs/qos-overview)). They count in a way that matters for application design: - Each 1 MB of data counts as one I/O. - **Every metadata request counts as one I/O too**: a create, delete, rename or attribute change as a write, and a lookup, attribute read or listing as a read. An application that creates millions of small files or lists directories often can reach an IOPS limit long before a bandwidth limit. - A policy can allow a **burst**: while you use less than the limit you build up credits, which you can spend later to run above it for a while. If throughput flattens at a level you can't explain from the client side, ask your platform team whether a quota or a QoS policy applies to your view or your user. See also [performance](/develop/docs/dev-datastore-guides-performance). ## Endpoints and virtual IPs Clients connect to **virtual IPs** (VIPs), grouped in **virtual IP pools**. Each VIP is served by one of the cluster's CNodes (its protocol servers). A pool can be limited to one tenant. Views can be limited to certain pools. You usually get a DNS name rather than an address. The cluster's own DNS server returns one VIP from the pool per query, so successive lookups spread clients over the pool. A single long-lived connection stays on one VIP, and so on one CNode. That's why [performance](/develop/docs/dev-datastore-guides-performance) is mostly about using many connections across many VIPs. ## See also - [Multiprotocol access](/develop/docs/dev-datastore-guides-multiprotocol). - [S3 compatibility](/develop/docs/dev-datastore-reference-s3-compatibility). - KB: [Overview of Multi-Protocol Storage Access](/docs-5-5/docs/overview-of-multi-protocol-storage-access) and [Controlling File and Directory Permissions Across Protocols](/docs-5-5/docs/controlling-file-and-directory-permissions-across-protocols).