[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <yq1sk0l3fig.fsf@sermon.lab.mkp.net>
Date: Mon, 04 Oct 2010 15:49:11 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: "Ted Ts'o" <tytso@....edu>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Mike Snitzer <snitzer@...hat.com>,
Eric Sandeen <sandeen@...hat.com>,
Jens Axboe <jaxboe@...ionio.com>,
"James.Bottomley\@hansenpartnership.com"
<James.Bottomley@...senpartnership.com>,
"linux-scsi\@vger.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-ext4\@vger.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: I/O topology fixes for big physical block size
>>>>> "Ted" == Ted Ts'o <tytso@....edu> writes:
Ted,
Ted> OK, but what do we do when we start seeing devices with 8k or 16k
Ted> physical block sizes? The VM doesn't deal well with block sizes >
Ted> page size.
I don't think we're going to see devices reporting logical blocks bigger
than 4KiB anytime soon. Too much pain for everybody in the industry
(most other operating systems can't even deal with 4KiB logical blocks
yet). Eventually we will have to do the required page cache surgery to
support filesystem block sizes bigger than the page size. But I don't
think that's something we'll have to deal with in the immediate future.
In the meantime, however, the question is whether there is something we
can do in the allocators to mitigate effects of devices reporting
physical blocks bigger than PAGE_CACHE_SIZE. Obviously this would be in
the I/O hint/alignment category and not something which would guarantee
that all writes would be aligned multiples of that physical block size.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists