Right -- I know it isn't the filesystem block size.
In this day and age, it seems anachronistic. Given the 10% higher block
density, not only would it yield higher capacities, but should yield higher
transfer rates, no?
I know it isn't a simple constant switch -- but I wouldn't want to switch
constants since not all disks should be constrained to the same block size.
Do other file systems have the same limitation? Are there any problems in the
linux-kernel with non-512 byte blocks?
-linda
-----Original Message-----
From: Stephen Lord [mailto:lord@xxxxxxx]
Sent: Sunday, September 29, 2002 2:59 PM
To: L A Walsh
Cc: linux-xfs@xxxxxxxxxxx
Subject: Re: block size in XFS = hard coded constant?
On Sun, 2002-09-29 at 16:28, L A Walsh wrote:
> I wanted to use an alternate block size on my SCSI hard disk.
>
> I did a low-level reformat to use 4096 and got an additional 10.3% in hard
> disk space. (17783MB -> 19627).
>
> I can't think of a reason why I'd want to have a 512 byte block when the
> smallest allocation unit on a disk is 4K.
>
> However -- I ran into a hard coded reason with XFS -- it's hard coded to use
> 512 byte blocks.
>
> Is there a reason for this? Am I missing something? Is it a bug, or is there
> some reason why xfs can't handle different sized blocks?
>
> -l
>
Its pretty hard coded in the code that the disk is addressed in 512 byte
sectors. Changing this has been discussed, but it is more complex than
just changing a constant in the code. The original design while very
scalable, did not consider sector sizes over than 512 as being a
possibility. Note that this is not the filesystem block size, most
metadata is 4K in size by default.
Steve
|