From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: [RFC] Draft Linux kernel interfaces for ZBC drives Date: Tue, 4 Feb 2014 11:27:33 -0500 Message-ID: <20140204162733.GE12768@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: HanBin Yoon Return-path: Received: from imap.thunk.org ([74.207.234.97]:54098 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752629AbaBDQ1g (ORCPT ); Tue, 4 Feb 2014 11:27:36 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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