Using SVOS Data Reduction (ADR)

Storage Subsystem Administration Guide for Hitachi NAS Platform

Version
15.7.x
Audience
anonymous
Part Number
MK-92HNAS012-37
ft:lastEdition
2026-10-02

The Hitachi NAS Platform currently offers hardware accelerated, fixed block de-duplication as a base feature of the HNAS Operating System. It is a commonly deployed feature of the HNAS OS that is adopted by many customers. The fixed block de-duplication does not include data compression.

As such some customers, have expressed an interest in leveraging the native compression capability offered in SVOS ADR in conjunction with HNAS de-duplication to extend capacity savings and lower storage costs. With the introduction of VSP One File Models, HNAS OS file system de-duplication was deprecated in favor of using SVOS ADR, which consistently provides better data reduction.

Customers typically deploy HNAS with thin-provisioned HDP Pools, which is recommended as best practice since the HNAS OS Server 12.1 release added the HNAS HDP Integration Support. In most HNAS customerenvironments, HNAS spans or pools are created on HDP Pools that are over-provisioned at a factor of 200-300%. This setup allows customers to easily scale HNAS capacity incrementally with zero disruption and automatic load-balancing. HNAS can obtain available free space from the storage system using SCSI based commands, such that the HNAS will never allow capacity to be provisioned beyond the currently assigned capacity to the associated HDP Pool, thereby safeguarding the file systems from unexpectedly running out of capacity during a file system expansion operation.

SVOS ADR does not report its data‑reduction levels or the actual physical pool usage back to the host HDP pool. As a result, the reported pool utilization and free space constantly change based on the type of data stored and how effectively that data can be reduced. As the data in the pool changes, the ability of the system to reduce the data also changes, which causes available free space to fluctuate.

Since free space is always shifting, managing available capacity becomes more difficult. Even file systems that could expand earlier, when free space appeared to be available, may no longer have that physical space available later.

For example, consider a scenario where an administrator creates a file system primarily used to store highly reducible data, for example, .txt files or logs, that is expanded several times to accommodate data growth. If the data within the existing file system is later deleted and replaced with unreducible data, for example, video or images, the logical capacity of the file system may be unchanged, but the required physical capacity would increase substantially. In such a scenario, the HNAS cannot prevent the file system from exhausting physical capacity before the exhaustion of logical capacity because the logical capacity was already allocated and therefore available to the operating system. If not monitored, this could lead to a file system or pool write failure due to lack of physical free space, which would make both the file system and its hosts span go offline until more physical capacity is added to the underlying HDP Pool. It is therefore important to carefully plan and monitor the use of SVOS ADR with HNAS. Specifically, HNAS administrators who choose to utilize SVOS ADR should carefully monitor the available physical free space of the HDP Pool and maintain an adequate amount of free space in the pool. While the block storage array can report data reduction statistics and available free space, it cannot account for the HNAS capacity associated with vacated span chunks or file system free space. Vacated chunks are HNAS storage pool chunks that were allocated from the HDP Pool to the HNAS span, but whose host file system was deleted . The HNAS considers the capacity as free space that is re-usable by other file systems in that span, but the block array simply considers this as allocated capacity.

The use of file system auto-expansion is still supported and encouraged but should be carefully monitored to prevent “runaway” expansion. The use of virtual volume hard quotas can also be used to serve as flexible partition boundaries, to help manage capacity utilization.

While VSP One File Administrator can now report Block pool statistics for certain VSP One Block arrays to further aid File Administrators so that they can closely manage available physical free space, customers who choose to use SVOS ADR must acknowledge and understand that free space management should be performed by consulting both the HNAS in terms of logical utilization but also the storage array in terms of physical utilization.