On Tue, Feb 04, 2014 at 02:00:58AM +0000, HanBin Yoon wrote: > > Just a minor point, but I noticed that the specification (14-010r1) had an > ordering for these flags in the zone descriptor format (Table 6) in a > different way from the above #define's. I thought it might be handy to have > these sync up? For example: Sure, making them line up would mean make it a little easier to translate from the response from the drive to the Linux kernel structure. > > * If free_sectors_criteria is positive, then return zones that have > > * at least that many sectors available to be written. If it is zero, > > * then match all zones. If free_sectors_criteria is negative, then > > * return the zones that match the following criteria: > > * > > * -1 Return all read-only zones > > * -2 Return all offline zones > > * -3 Return all zones where the write ptr != the checkpoint ptr > > "all" above for -1/-2/-3 is still limited by (int) max_zones, correct? Good point, that is what I intended. We can better clarify this replacing "Return all..." with "Match all...". > I was also wondering whether the returned (struct) zone_status'es should > have any ordering, e.g., if they should preserve the ordering given by the > drive. According to the specification for REPORT ZONES, "The descriptors > shall be sorted in ascending order based on the zone start LBA value." If > this ordering is preserved, maybe it will help to reduce seek distance > (assuming correlation between ascending LBA and going from OD to ID)? Yes, I was assuming they would be returned in ascending LBA order, but we should explicitly specify this in the interface specification. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
