From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Topology ioctls Date: Wed, 23 Sep 2009 19:28:33 +0100 Message-ID: <20090923182833.GC23822@shareable.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Eric Sandeen , Andreas Dilger , Jim Meyering , jens.axboe@oracle.com To: "Martin K. Petersen" Return-path: Received: from mail2.shareable.org ([80.68.89.115]:40870 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752388AbZIWS2c (ORCPT ); Wed, 23 Sep 2009 14:28:32 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Martin K. Petersen wrote: > > The original rationale for exporting the topology information via sysfs > was that we intended to support multiple heterogeneous regions within a > block device. And that fit poorly with an ioctl approach. > > However, with a single region per device it is trivial to provide the > topology. And while mkfs.* will continue to use the libblkid interface, > there are users that would like to get access to this information > without having to traverse sysfs and stitch things together manually. Quite nice, I can see it coming in handy. One more bit of information I'd like is the "write affected block size". When you write to a single disk, it's the sector size (512 or soon to be 4096). For a RAID, it's probably quite large, depending on implementation details. For some kind of flash - see threads from Pavel and LWN about sector writes causing erase-block sizes to be lost. That size is useful to any program which does journalling/logging type of write pattern, i.e. databases and filesystems-in-a-file, so they can write new commit blocks sufficiently far apart. -- Jamie