Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262138AbUDJWXv (ORCPT ); Sat, 10 Apr 2004 18:23:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262143AbUDJWXv (ORCPT ); Sat, 10 Apr 2004 18:23:51 -0400 Received: from mlf.linux.rulez.org ([192.188.244.13]:19984 "EHLO mlf.linux.rulez.org") by vger.kernel.org with ESMTP id S262138AbUDJWXu (ORCPT ); Sat, 10 Apr 2004 18:23:50 -0400 Date: Sun, 11 Apr 2004 00:23:47 +0200 (MEST) From: Szakacsits Szabolcs To: viro@parcelfarce.linux.theplanet.co.uk Cc: Andries Brouwer , fledely , linux-ntfs-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: Accessing odd last partition sector (was: [Linux-NTFS-Dev] mkntfs dirty volume marking) In-Reply-To: <20040410211301.GW31500@parcelfarce.linux.theplanet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 819 Lines: 21 On Sat, 10 Apr 2004 viro@parcelfarce.linux.theplanet.co.uk wrote: > 2.4 logics around block size handling is broken; we probably could backport > that series of patches, though. 2.6 simply sets block size to GCD(page size, > device size), so we don't have to worry about all that crap. That's great! Just one question, in the most common cases the block size ends up between 512 and 4096 bytes. Depending on how this block size used, it can have a significant impact on performance (e.g. 512 vs 4096). Is this true or is it used to be performance independent? Szaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/