Symm Cache page size

DMX3 uses 64Kb tracks.

If this 64kb,how DMX going to address the databases blocks -Sybase(2k),Exchange(4k),SQL(8k) and oracle(16k).Does it give better performace in clariion if set to particular block size per cache page compare to DMX?

Or is this block size,when used for raw file systems(no volume management layer).In this case how can we acheive better performace?

If the Volume manager is present,Windows(32k) and unix(64k) going to mask all the writes?What's about the reads?Still DB needs,for example sybase still nees 2k..how does DMX address this need?

Is there any parameter in DMX to set this behaviour per OS/per Database?I am thinking of cache partitioning per DB..is that a better option?Any drawbacks of doing this?

A lot of questions .. A lot of good questions ..

1) 64K is the size of a track. The backend reads/writes always full tracks. Thus the dialogue between the cache and the disks happens at 64K blocks.

2) you mentioned a lot of different applications/operating systems/variables that affectdialogue between the host and the frontend. But remember you always have the cache in between.

3) DMX offers SCSI disks to the hosts.

4) When an host wants to write/read something, it have to specify both the starting block and the size of the operation. The DMX will find how many tracks are needed. If the IO operation is smaller then 64K, each operation will touch at most 2 different tracks. If the IO operation is bigger it may need more tracks.

5) Let's dig what happens when the host wants to READ from the DMX. As soon as the Frontend receives the IO from the host, it will search required tracks in cache. In case one or more tracks aren't yet in cache, the frontend will ask needed tracks to the backend. As soon as the tracks are in cache, the I/O is fulfilled and the answer (the data) is returned to the host.

6) What happens when the host wants to WRITE to the DMX?? If the tracks being written are already in cache, the FA processors will put data in cache. If tracks aren't yet in cache, FA will search for available slots and put data in available cache. If there is no available cache slot the FA will ask DA to destage something and as soon as there is an empty cache slot the FA will write data in cache. As soon as all written data is in cache, the FA returns an ACK to the host.

It's easy to note that block size and alignment can affect the DMX (bad alignment and/or small random IO ops will put more pressure on the backend). It's also easy to note that io size will affect host-FA performances.

AFAIK there is no parameter you can tune in the DMX per OS or per DB. DCP may help in having predictable performances in MC environments.. But I don't think to DCP as a "parameter"

Stefano,

1) Disk IO in the Symm does NOT only happen with whole tracks. The minimum IO size to the backend is a 512 byte block. However for user data, we need to perform IO at the sector level which is 8k in DMX3 and above. So if the user wrote only one 512 byte block, when we destage it, we need to read the other blocks in the sector first, then we can merge the new data into that sector, and write the 8k to the disk.

4) A 512 byte IO will never occupy more than one track.

6) The front-end won't ask the DA to destage something, it will simply wait until there is a slot available.

And back to my response to #1, you can see that it can be helpful not to do partial sector writes.

4) that's why I said "at most"

I love to receive corrections !!

Maybe I'm reading more into it than I should be (guessing that the OS and DMX cache should normally coalesce those writes into a single larger sequential write provided they are not random), but would it be beneficial to create a filesystems with a blocksize of 8k if possible, so that I don't have to do a read + write for writes; thereby forcing host level writes to always come in at 8k to the DMX?

You would probably only apply this method on well known filesystems where files are generally >8k but have small write I/O systems; as there would be a space detriment to filesystems with large numbers of files <8k since you would have a bunch left in sloack; but if I'm thinking correctly could doing this give rather significant backend disk benefits? I could be completely off base here so correct me if I'm wrong.

The DA won't wait for a track to be filled before destaging, however as long as there is not a rush to destage (cache filled with writes), the DA can let the slots age before destage, which can allow re-writes to the same track or data (avoiding a destage operation altogether) and also allowing adjacent blocks to be written, allowing coalescing of data, also saving IOs on the backend.