From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D3E657F37 for ; Wed, 23 Sep 2015 05:28:43 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 610B8AC005 for ; Wed, 23 Sep 2015 03:28:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id fOrB5jgalz6iBBpr (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2015 03:28:39 -0700 (PDT) Date: Wed, 23 Sep 2015 12:28:34 +0200 From: Carlos Maiolino Subject: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Message-ID: <20150923102834.GA4490@redhat.com> References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> <20150922122238.GA46026@bfoster.bfoster> <20150922220054.GL19114@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150922220054.GL19114@dastard> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Dave Chinner Cc: Brian Foster , xfs@oss.sgi.com Howdy folks, I was working in implementing the suggested feature in my patch, about getting the next inode used after one is provided, and I hit something that I'm not really sure if this might be considered a bug, or just a work form. XFS_IOC_FSINUMBERS, is supposed to be called with a zeroed xfs_fsop_bulkreq.lastip, so at each call, kernel will update this number to the last inode returned, and, the next call will return in xfs_inogrp.xi_startino, the next existing inode after .lastip. So, I was expecting that, passing a non-zero .lastip at the first call, I would be able to get the next inode right after the one I passed through .lastip, but, after some tests and reading the code, I noticed that this is not the case. The problem (not sure if I can really say it's a problem), is that, if the inode number passed, happens to be somewhere in the middle of an inode chunk, the whole chunk will not be printed, only the next inode chunk will start to be printed, hiding all information of the previous one. I'm not sure if this is the desired behavior or not, but, I'd say that, if the inode passed in .lastip, is not the first in the chunk, the output should start for its own chunk, instead of the next one, but, I prefer to see you folks POV before starting to fix something that I'm not sure if it's actually broken :-) Cheers -- Carlos _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs