A request to find shared documents by path is different from a request for a host to attach a storage volume.
This hypothetical app example separates the two access requirements, then shows what to confirm before treating either as a necessary part of the design.
Data center fundamentals series
What does each request ask to access?
The distinction is who needs access and through what interface: a team member needs a file path, while a host operating system may need an attached volume. Consider a hypothetical business app with two separate requests. Walking through them shows why the names of the app and its components are not enough to choose storage.
First, team members want to find, read and edit a proposal at a shared path such as /team/docs/proposal.pdf. That path is illustrative, not a required directory structure. This is a file-access requirement: people or applications need to locate files through folders and directories, and authorized users need access to the shared data.
The path alone does not specify who may read or write, or whether sharing and file locking are needed when people work on the same file.
Second, suppose the app’s database component explicitly requires a storage volume attached to its host operating system. If that is its actual requirement, classify it as a block-volume request. Block storage can provide a raw volume for a host to connect to; its blocks have addresses, but that does not mean team members must know those addresses.
Confirm which host needs the volume and how the operating system will format and manage it. A block volume has no inherent file system, so providing that volume is not the same request as providing the team with a shared file path.
Nor does the label “database” prove a block volume is required: IBM describes block storage as a database use case but also discusses database data in its file-storage account. The component’s actual interface requirement still needs checking.
IBM — What Is Block Storage? | IBM
IBM — What Is Data Storage? | IBM
IBM — What Is File Storage? | IBM
Could a file path sit above a block volume?
Yes. In one possible arrangement, a host attaches and formats a block volume, then shares files through its operating system. Seeing a file path at the user-facing layer therefore does not rule out block storage underneath. Conversely, attaching a block volume does not by itself create a shared path for the team.
This is an interface distinction, not a speed ranking. File counts and the app’s performance needs may matter in a real evaluation, but this hypothetical app has no measured results. Neither approach is established as universally faster, and the example does not establish that the app needs both.
How can the two requirements be written down?
For this hypothetical app, record two questions rather than assuming two storage purchases:
- Team documents: Must users find and share files by path under specified permissions? Who can read or write, and is file locking needed?
- Host component: Does it actually require a block volume that the operating system will attach, format and manage? If so, which host will use it?
If the answer to the second question is no, this example does not yet justify adding a block volume. Before a real design decision, confirm each component’s access interface and document shared-access permissions and failure-protection and recovery requirements separately. Choosing block storage alone does not establish redundancy or recovery.
The useful next step is to verify the component requirements before turning this classification into an architecture.
No comments:
Post a Comment