Sectors in Zonned Bit Recording

As far as I can tell there is no standardisation as to how drive manufacturers utilise ZBR or ZCAV. From what I've seen on some of the older drives the number of tracks per zone is the same yet on others its variable and may increase the further away the zones are from the edge of the platter. Typically as far as I can tell the number of zones remains more or less a constant on most drives at in and around 15 zones, but the number of sectors per track will increase incrementally the closer  to the edge of the platter the track is ( in some cases you will see double the amount of sectors on the very outer tracks compared to the inner most tracks). I think its pretty much down to the manufacturer to employ an effecient methodolgy as to how they use ZBR.

The attached document goes into a fair amount of detail on the subject...  some bed time reading for you...

Hello Sheetanshu and Marty (first bullet),

Correct. Each physical disk sector has a unique address (eg CHS), and some allocation for house-keeping. The address of the physical disk sector can be held within the sector itself. This enables the heads to verify their location.

Best regards, Richard.

Thanks for valuble replies

What i think , there should be something standard deciding factor , because during logical addressing mapping is performed & for that mapping algorithm we have to provide some standard algo , so there must be some deciding factor for sectors/tracks

?

Hello , Brother Richard

Yes , i am looking for the relationship between CHS & logical address,

logical address is assigned by the OS , and as far as i know same OS will work for different disk {having different sector/cylinder combination} , so question stands how Os will give the logical no. to a particular sector {having CHS info within the sector} ?

Thanks

Hi Sheetanshu,

I may have mis-interpretted you're question. But just incase I haven't the LBA is defined as follows :

Cylinder x head x sector - 1   = LBA address

Hello Sheetanshu,

Good question.

Each physical disk block has a unique physical address - CHS. (Actually, in this scheme, CH identifies a unique track, and so CHS identifies a unique disk sector within that unique track). For an open systems disk, the sector size will be 512B (=1/2 KB).

When the drive is formatted, each disk sector (CHS) is assigned a logical block address. Also, when the drive is formatted, then it is formatted 'down' a cylinder, so logical block 0 -> logical block N-1 all exist within one cylinder (where N is the number of sectors in that cylinder). Logical block N is then located at the start of the next cylinder, and this next cylinder contains disk sectors N -> 2N-1.

When, for example, you build a filesystem in UNIX, the filesystem has a configured filesystem block size (referenced in the filesystem Superblock). Let's imagine that the filesystem block size is 8KB, which is 16 disk sectors. Each  file in the filesystem has an i-node that holds meta-data for that file. The i-node will contain the logical block address of  the start location of the first 10 (say) filesystem blocks for that file. The filesystem driver will request the first filesystem block, which, via the SCSI protocol, and through the SCSI controller/interface on the drive, will request 16 logical blocks from the drive (these 16 logical blocks will be sequentially contiguous disk sectors). The drive can map the logical block address requests to the unique CHS sector address. (For the addresses of the start location of filesystem blocks, for that file, after the 10th (in my example) the i-node points to a disk logical block address of an 'indirect' block, which holds the start location of, say,  the next 256 filesystem blocks making up the file. After this there are double and triple indirect blocks).

Also, to improve performance, when accessing the filesystem via block access, UNIX will utilise a filesystem buffer cache in memory on the file server.

(BTW, the drive is formatted 'down' a cylinder in order to improve the sequential throughput (MB/s) of the drive; the drive reads the sectors in the first cylinder, and this is purely an electro-magnetic operation. We then have the electro-mechanical operation of the moving the heads to the next track, and then we can read the next cylinder.  The random I/O performance of the disk (IOPS) is improved through the use of the command tag queuing technology).

HTH, Richard.

Hi Marty,

Just seen your last post.... I think we have said the same thing

I know my question is not directly about the physics of ZBR, bur I'm wondering what the effect of ZBR is on alignment of Wintel hosts. A lot of fancy calculations can be done to prevent misalignment per disk, per Raid Group and improve data throughput when the proper alignment is used.

Since aligning partitions is done by putting the starting sector of a partition on a certain place on disk, I am wondering if alignment should be different in the beginning of a disk compared to a partition no the end of a disk.

Any thoughts ?

I don't quite follow you, since aligning is not about logical view of disks, but indeed the physical view of disks.

IMHO aligning a partition means that clusters of data (also known as blocks) don't involve hard drive head movement, since that takes (a bit of) time. Since in the outer regions there are more sectors per track, aligning would mean you'd have to take more sectors out than when you'd place a partition on the inner tracks where there are less sectors per track. So IMHO the alignment in the outer regions would be for example 96 sectors (96 sectors per track) and only 24 on the inner regions (the 24 and 96 are random numbers I made up just now, since I don't ahve a clue how many sectors there are on a disk).

Aligning is all about getting rid of (as much as possible) the physical part of a disk: movement of the heads.

In 2 EMC performance workshops (Clariion as well as DMX) I was told that the rule of thumb is 128 sectors for DMX and 64 for Clariion and that we shouldn't think too much about ZBR, since that would make life much harder, especially when you're migrating LUN's around in Raid Groups. If a LUN could be bound to a fixed position on a Raid Group, thinking about aligning relative to the ZBR specs would make sence, but since LUN's can move around (on demand) it can be bad to use different numbers to align partitions to.

Hello TrippleR,

As you know,  the common reason to manage alignment is to ensure that the logical address space seen by the host application (eg filesystem) starts on a logical stripe boundary; there are some subtle differences as to whether it is array-based alignment or host-based alignment.

The alignment offset would depend on, for example, the size of the OS or BIOS metatdata that is written at the start of the logical address space (ie. at the start of the array stripe).

I cannot see any reason why the standard alignment rules would change due to ZBR, since you are aligning the logical address space to start on a logical stripe boundary.

Another way of looking at it is this. Lets imagine that a RAID-0 element size is 64KB and the stripe width (number of disks in the stripe) is 4. In that case:

element size x stripe width = stripe size

=>   64KB x 4 = 256KB

This equation and its result would not change if the LUN began on the outer sectors of a disk or on the inner sectors of a disk. The 64KB element size would be made of contiguous physical disk sectors within a disk; and for this purpose it does not really matter where those sectors are.

In your question below you say "Since aligning partitions is done by putting the starting sector of a partition on a certain place on disk", I think it is better to think of alignment as putting the starting sector of a logical partition on a logical stripe boundary.

HTH, Richard.

Hello RRR,

When we align, then we are really aligning the logical address space that the host application uses such that it is aligned on a stripe boundary (but, as you correctly point out, the ultimate aim is to utilize the physical layer in a more efficient way).

In the example I gave above:    64KB x 4 = 256KB = stripe size               - just an example.

For the sake of this explanation, let's imagine that the logical address space seen by the host application begins at the start of the first stripe (because it has been aligned on a stripe boundary). Also, for the sake of this explanation, let's assume that the host happens to be doing sequential access to the logical address space and is requesting 256KB. This request can be satisfied by reading 64KB from each disk in parallel, and this would be great for performance. In parallel, we would have:

disk 1 - return 64KB

disk 2 - return 64KB

disk 3 - return 64KB

disk 4 - return 64KB

Now let's imagine that, at the beginning of the first stripe, the host has placed some metadata (eg. a signature or an MBR of some kind). This would mis-align the logical address space that is left for the host application because the 'application' stripe would be pushed along to the right-hand side, and then wrap around back to the first disk. For the sake of argument, lets imagine that the metatdata written by the host that causes the mis-alignment is 32KB; in this case, when the host requests 256KB of data, this is what would happen:

disk 1 - return 32KB

disk 2 - return 64KB

disk 3 - return 64KB

disk 4 - return 64KB

disk 1 - return 32KB     (because of the wrap-around).

(This 32KB wrap-around back to disk 1 would be satisfied by a different stripe element than the first 32KB access to disk 1, and this could result in more latency caused by head movement).

I know that my example is for sequential I/O. But there are similar benefits for random, which is probably the more common commercial I/O profile. For random I/O, it is most efficient if each random I/O request is serviced by a single drive, if one random I/O request is serviced by two drives then this is less efficient and is sometimes referred to as a drive crossing. Actually, imagine the the application is doing random I/O, and that each I/O size is 64KB, then, in my example of a 64KB element size, every I/O would result in a drive crossing.

Actually, I am beginning to wonder if we are talking about different types of alignment, or whether I am completely missing the plot, which is also completely possible

I think your courses were correct - do not worry about ZBR.

Does this explanation make sense ?  Please let me know.

Thanks, Richard.

Hello again RRR,

It occurred  to me, over the weekend, that we are probably talking about different types of alignment. My discussion above is relating to aligning the logical address seen by the host so that it begins at the beginning of a logical stripe boundary; as discussed, this reduces drive crossing at the physical layer. I think all of this is fine.

I think what you may be referring to is the physical placement of the data on the platters. What may be important here is the following:

• an inner track has a smaller radius from the centre of the spindle.
• an outer track has a larger radius from the centre of the spindle.
• therefore, the outer track has a larger circumference than the inner track.
• with ZBR, the outer track holds more sectors than the inner track (since the track is physically longer).
• ZBR means that the drive vendor maintains an efficient footprint density when moving from inner to outer tracks.
• all tracks have the same angular velocity. (Angular velocity can easily be measured in RPM. All tracks have the same RPM).
• let's say the outer track holds 'N' sectors, and the inner track holds 'n' sectors; then N>n.
• In a single revolution, a r/w head can read 'N' sectors from the outer track.
• In a different single revolution, a r/w head can read 'n' sectors from the inner track.
• this means that the amount of data read, in a single revolution, is greater for an outer track than for an inner track.
• for inner tracks to satisfy reading 'N' sectors, then several mechanical track-to-track seeks would need to occur.
• hence, the transfer rate in MB/s is greater for an outer track.

For this reason, if there are requirements for a particular stripe to have a higher sequential throughput than another stripe, then it may be beneficial for the stripe to be configured to use outer tracks, as opposed to inner tracks.

This was certainly the case in several benchmark projects that I was involved in many years ago (~10). However, with reduced track-to-track seek times, and also with enterprise arrays effectively designed to be RAID engines (for RAID performance and with many intelligent cache algorithms), I am not sure how much of a difference you would now notice.

Best regards, Richard,

Small correction from my last post:

First paragraph, second sentence:

"My discussion above is relating to aligning the logical address seen by the host so that it begins at the beginning of a logical stripe boundary"

Should read:

"My discussion above is relating to aligning the logical address seen by the host application so that it begins at the beginning of a logical stripe boundary"

Richard.

Richard,

thanks for tuning in on my frequency .

So you're in fact saying that aligning would make sence if the array wasn't so incredible efficient handling the data ? It now comes all back to my instructor's remark saying that we don't need to bother about alignment anymore taking ZBR into account.

So from now on we simply asume that accross the whole disk whether inner or outer track there is an equal amount of sectors.

It sure makes life a lot easier, but somewhere I still wonder if - for very specific applications - it's worth the trouble of aligning partitions on the outer tracks related to the number of sectors over there. I say very specific apps, but then again: if performance is that important one should simply consider SSD .

Hello TripleR,

Yes, it did hertz my brain a little, until I tuned into the correct frequency

All my comments above have really been industry technology-focused and not related to any specific product.

Yes, I think that, with the amazing engineering in modern enterprise arrays, it is generally not necessary to be concerned with the details of ZBR; that's for the drive vendors to be concerned about. Having said that, I guess there may be occasional exceptions, and those can be investigated by proof of concept.

I do not deliver the Cx, Symm performance workshops; someone on this forum may have direct experience here.

Cheers, Richard.