Sectors in Zonned Bit Recording

Hi Sheetanshu,

     I'm sure if you looking for a formula for designing the best layout of a zoned bit disk or a formula for calculating the number of sectors that a ZBR disk has?

If that latter, I believe most drive manufactures will give you a table that lists the number of zones, including the number of sectors each zone has and the transfer rate for that zone.

If the former, I believe it would depend on many factors like the recording bit density, trade-offs between constant linear velocity and constant angular velocity.

Just my 2 cents. I'm curious to hear what others who may have much deeper experience with different recording formats. Maybe someone who has some experience with disk drives directly?

   --Kindly, Marty

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.

• Since the R/W head needs to stay suspended above the platters on a cushion of "ground effect" air, I'm sure that linear velocity at the R/W head is part of any drive's engineering design considerations. My guess is that constant linear velocity must be more complex as the drive motor would need intelligence about where how far out from the spindle the R/W head is as well as accurate velocity across the entire range that the motor is asked to supply. I'm guessing that it's much cheaper to produce a drive that has a constant angular velocity and then combine it with ZBR to not waste sectors (capacity). It can be argued that at least in the consumer or SMB market, that price is EVERYTHING when the end user is attempting to purchase the capacity they need.
• I understand that for a given magnetic material there is a physical limit to the amount of polar state changes that one can pack into a particular 2 dimensional space. I believe this is where the encoding algorithm comes into play attempting to encode data in the least number of bits or (pole changes). I'm thinking about MFM or RLL as encoding schemes but I'm sure these must be old now and some new higher density scheme is what is used today?
• I can only imagine that when a drive designer thinks about building a drive they are thinking of maximizing performance with cost. It would seem to me that performance can be impacted by seek times and keeping the number of track seeks to a minimum is a good strategy.
  Also CAV will keep costs and complexity down. I'm guessing that maximizing utilization of those outer high linear velocity tracks is also advantageous and ZBR can help with this.
  I can only imagine that ZBR comes at the cost of more firmware code that needs to track the more complex sector layout.

Thoughts?

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

?

Hi Sheetanshu,

    I believe that the abstraction of the CHS tuple to LBA address is something that is done on the SCSI drive controller board.

I belive that all OS SCSI disk drivers would use the same LBA address scheme and simply format the LBAs with their own propriatary volume format (NTFS, EXT3, JFS, ZFS, etc).

--Kindly, Marty

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

Hi Richard,

     Enjoyed your last post.

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.