flashcaceh and flashlog exadata

If you view the default properties of a cell where create flashlog all was run first, list flashlog will output a strict 512M size attribute per cell:

Bash

CellCLI> list flashlog attributes name, size
         dm01cel01_FLASHLOG     512M

Because create flashcache all allocates the remaining space, you can calculate the exact difference. For example, if a flash disk pool has exactly 3,000.00 GB of raw physical space, after running both commands, your flash cache size will show up as exactly 2999.50 GB (3000 GB - 512 MB)

Plaintext

[root@dm01db01 ~]# dcli -g ~/cell_group -l root cellcli -e list flashlog attributes name,size
dm01cel01: dm01cel01_FLASHLOG 512M
dm01cel02: dm01cel02_FLASHLOG 512M
dm01cel03: dm01cel03_FLASHLOG 512M

Even though flash memory is fundamentally much faster than spinning disks (HDDs), there are scenarios where the write to the spinning disk completes before the write to the Smart Flash Log.

1. The "Race" Architecture (Simultaneous Writes)

When the database Log Writer (LGWR) issues a redo write, Exadata does not wait for flash first and then write to disk. Instead, the Exadata cell software issues the write command to both media types at the exact same time:

• It writes to the spinning disk controller cache.

• It writes to the Smart Flash Log (Flash NVMe/PCIe).

The architecture is explicitly designed so that whichever media responds first wins. The cell immediately sends a success acknowledgment back to the database LGWR, and the slower write is discarded/ignored.

Flash drives are subject to internal housekeeping tasks managed by the SSD controller, such as Garbage Collection and Wear Leveling. a flash drive is currently busy restructuring blocks or clearing out old pages to prepare for new writes, it can experience a brief, temporary spike in write latency

During that brief flash hiccup, the spinning disk will easily win the race.

 running create flashcache all does not create the flashlog, but it does reserve space for it if the flashlog already exists.

The behavior depends completely on whether a flashlog was created before you ran your command:

Case 1: The Flashlog already exists (Standard Setup)

If your cells already had a flashlog configured (which is the case 99% of the time in enterprise environments), running create flashcache all automatically respects and reserves that space.

• Exadata calculates the total physical flash capacity, subtracts the space currently allocated to the existing flashlog, and gives 100% of the remaining space to the flash cache.

• It will not overwrite, delete, or shrink your existing flashlog.

Case 2: The Flashlog does NOT exist (Empty Cells)

If you are building or resetting a cell completely from scratch and it has neither a flashcache nor a flashlog:

• Running create flashcache all will consume 100% of the raw physical flash space for caching.

• It will not automatically create a flashlog for you.

• If you try to run create flashlog all afterward, the command will fail with an error stating there is no free space left on the flash disks.

💡 The Correct Sequence

If you are performing maintenance and need to rebuild both, you must always create the flashlog first, and then let the flashcache claim the rest:

Bash

# 1. This grabs its tiny, default 512MB per disk slice first
cell_group -l root "cellcli -e create flashlog all"

# 2. This grabs all remaining space safely, reserving the flashlog space
cell_group -l root "cellcli -e create flashcache all"

How to verify your current status right now

Since you just ran the command, you can check if your flashlog is safe by running this:

Bash

cell_group -l root "cellcli -e list flashlog"

• If it returns status normal, you are completely fine—your flash cache safely grew around it.

• If it returns empty or an error saying no attributes exist, you will need to temporarily drop the flashcache (drop flashcache), create the flashlog first, and then re-run your create flashcache all command.

Neither of these commands creates physical files that you can see via standard Linux commands (like ls), nor do they create disks directly inside Oracle ASM.

Instead, they create internal, cell-level logical constructs managed entirely by the Exadata storage server software (Cellsrv).

1. What create flashcache all creates

This command does not create a file system, a file, or an ASM disk.

It creates a system-managed logical caching tier across all the physical Flash NVMe/PCIe cards on that cell.

You cannot see this with ls / or df -h. The only way to see it is via the Cell Command Line Interface:

Bash

cellcli -e list flashcache detail


It is a very common point of confusion, but create flashlog all does NOT create disks in ASM. Just like the flashcache, the Smart Flash Log is an internal cell-level logical boundary reserved on the flash cards.
How it actually works: It creates a small, circular logical log buffer managed entirely by the storage cell software.
The ASM Connection: Your Database Redo Logs (*.log files) still physically reside inside your normal ASM disk groups (like +REDO or +DATA) which sit on regular hard disks.
The Magic: When the database writes to an ASM redo disk, the Exadata cell software recognizes it as a redo write. It intercept the write and pushes it to both the spinning disk (via ASM) and this internal, hidden flashlog space at the same time.
So, ASM never mounts, sees, or manages the flashlog. ASM just thinks it's writing to a normal disk—Exadata does the double-write behind ASM's back to make it faster.