From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Staubach <staubach@redhat.com>
Subject: Re: Expected getdents behaviour
Date: Thu, 15 Sep 2005 10:03:29 -0400
Message-ID: <43297F31.6050902@redhat.com>
References: <e483447805091506573daebc21@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mx1.redhat.com ([66.187.233.31]:18827 "EHLO mx1.redhat.com")
	by vger.kernel.org with ESMTP id S964963AbVIOODe (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 15 Sep 2005 10:03:34 -0400
To: Akshat Aranya <aaranya@cs.sunysb.edu>
In-Reply-To: <e483447805091506573daebc21@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

Akshat Aranya wrote:

>I noticed that bonnie++, in its directory tests, does the following on
>a large directory
>
>open(dir);
>while (getdents() != 0)
>{
>   unlink all the returned entries from getdents
>}
>close(dir);
>
>My question is whether the filesystem's readdir is expected to
>consider the offset value in the second readdir to still be valid,
>given that entries from the directory were deleted after the first
>readdir.
>

This "usually" works.  Most file systems do not directory compaction when
removing entries.  However, some do, so to be safe, the algorithm needs to
take into account this and also entries which can not be removed.

    Thanx...

       ps