#Fusion Workload Block Size and I/O Mix Configuration

1 messages · Page 1 of 1 (latest)

chilly robin
#

I am working on sizing a storage solution using Fusion.Netapp.com for a customer requirement and need clarity on the following points related to workload configuration:

  1. I/O Mix Ratios for Different Workloads
    In Fusion’s workload input, we need to specify Random Read/Write %, Sequential Read/Write %, and Block Size.
  • Example:For a CIFS-based file storage workload, we currently use 70% Random Read and 30% Random Write (both at 8K block size).
  • Questions: - What are the recommended I/O ratios for other common workloads (e.g., databases, virtual machines, web servers, backups)? - Is there a NetApp best-practice guide for these configurations?
  1. Block Size Selection Guidance
    Fusion allows selecting block sizes such as 4K, 8K, 16K, 32K, etc.
    -Questions:
  • How should we choose the block size for different workloads (e.g., 4K for databases vs. 32K for video editing)?
  • What are the performance implications of selecting 4K vs. 32K for:
  • IOPS (e.g., 150K IOPS target)? Throughput (e.g., 3 GBps target)?
  1. Conflict Between Fusion Block Size Options and WAFL’s Fixed 4K Block Size
    As per NetApp KB Article, WAFL uses a fixed 4K physical block size.
  • Questions:
    -Why does Fusion allow selecting larger block sizes (e.g., 32K) if WAFL uses 4K?
    -Does this relate to logical vs. physical block sizes? If so, how does WAFL handle larger logical blocks (e.g., splitting 32K into 4K chunks)?
  1. Changing Block Size for Existing Volumes
    We attempted to modify the block size of an existing volume using:
    vol modify -vserver vs1 -volume cifs_data -userblocksize 32k

However, the -userblocksize option was unavailable.

  • Questions:
    -is modifying the logical block size post-creation supported in certain ONTAP versions?
    -What is the recommended workflow to change the block size of an existing volume (e.g., data migration to a new volume)?
unique adder
#

  1. That really depends on your workload and you should always model with what you're actually seeing on your (existing) systems

  2. again, the block size is nothing you can "choose", it is defined by the application that is doing the I/O. Some databases do 8k I/Os, some do 32k I/Os, some might do 4k I/Os. It all depends on what applications you're using

  3. The IO sizes in fuision are the client I/O sizes, i.e. what your appliction uses. ONTAP breaks that down into smaller I/Os if required. There is no "logical" or "physical" block size

  4. No idea where you got the -userblocksize option from, but it doesn't exist and never existed. ONTAP blocksize is 4k and cannot be changed

chilly robin
#

@unique adder Thank you for your previous clarification. To ensure I model workloads accurately in Fusion, I have a few follow-up questions based on your guidance:

  1. General Read/Write Ratios for Common Workloads
    While I understand these ratios depend on specific applications, could you provide general starting points for common workloads? For example:

Databases: Is a 70% read / 30% write ratio a typical baseline for OLTP?

File Storage: Would 60–80% read / 20–40% write be reasonable for collaborative CIFS/NFS environments?

Backup/Archival, VDI, Virtual Machines: What are common industry trends for these workloads?

  1. General Block Size Guidance for Workloads
    Similarly, are there common block size patterns for key workloads? For instance:

Databases: Often use 8K–16K blocks for transactional I/O?

Backups/Media: Prefer larger blocks like 32K–128K for sequential writes?

File Storage: Vary between 8K (small files) and 32K (large files)?

  1. Client vs. WAFL Block Size Interaction
    You mentioned that Fusion’s block size represents the client/application I/O size, while WAFL uses a fixed 4K block. Could you confirm if the following understanding is correct?

Example: A client writes a 32K block via CIFS.

WAFL splits this 32K I/O into eight 4K blocks on the backend.

This process is automatic and requires no manual configuration.

unique adder
#
  1. I really can't go into specifics without knowing (and testing) your exact workloads. The numbers you quote are industry averages so there's a high chance they might apply to you, but there's also the chance that they are completely off
  2. Databases can use anything between 4k..64k usually. MS SQL server (I think) uses mainly 8k. Backups use larger I/Os, usually 64k up to 1mb. File storage uses whatever is needed (if you read a file that is 1445 bytes, then that's a 1445byte I/O)
  3. It depends. It could be that WAFL uses inline compression to compress the 32k down to 4k and then it's only a single 4k I/O. On writes, it doesn't matter anyways since you have NVRAM between the incoming I/O and the disks. For reading, it might well be that a single 4k I/O requires 2 backend I/Os if you have a misaligned I/O for example (read amplification)