From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiro SEKIBA Subject: Re: [CFD] disk format fixing Date: Thu, 06 May 2010 00:19:20 +0900 Message-ID: <871vdq74w7.wl%jir@sekiba.com> References: <87aash3rrm.wl%jir@sekiba.com> <20100504120623.GB1132@heethoofdje.13thmonkey.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Return-path: In-Reply-To: <20100504120623.GB1132-bVHBekiX4bNgoMqBc1r0ESegHCQxtGRMHZ5vskTnxNA@public.gmane.org> Sender: linux-nilfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Reinoud Zandijk Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Hi, > > It still remains controversial argument, like directory indexing or atime > > support, xattr support and so on. However, I'd like to make the target > > clear that when the above message can be taken away. > > I'd opt for not getting into directory indexing; that can easily be > implemented at run-time as i showed to with code in the NetBSD implementation. > The speed increase is really fenominal (can be 500+ times) and doesn't need > much memory space and doesn't involve a disc layout change. I agree with you that no getting into directory index, at least this time. Howerver, I don't agree (or disagree) with your on memory indexing idea yet. nilfs has there own btree functionality, therefore it is goot to be used for directory indexing if nilfs has it. So even ext3 htree format preserve both backward/forward compatibility and is well tested code base, maintaining both htree and btree code is not the best idea. thanks, regards, -- Jiro SEKIBA -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html