On the web page you sited, I read:
"...We are using pages to cache metadata, pages are
allocated one at a time, so each page sized chunk
of memory usually is not adjacent in the address
space to the page covering the next block of the
disk."
How does FreeBSD's UFS let you mkfs filesystems
with 16K FS pagesize? It is on same X86 architecture
as Linux!
Also, why does the XFS have to allocate metadata
pages that are same size as FS logical block size?
At the expense of trying to answer my own question,
I vaguely recall reading - and I might be wrong here -
that for very small files, the file data is stored
in the metadata (inode) page, which is only 1
mmu-sized 4K page.
Is this correct?, and if so,
a. Is this the primary reason why you currently only
support 4K FS logical block size?
b. Could this be removed, and make all data live in
seperate data blocks (extents) in the tree, as is
the case with large files?
c. Could it be made dependent on user selected block
size during mkfs? i.e., if user selects 4K blocksize,
then default to current implementation, else
let all metadata live in in pages seperately from
data.
Cheers,
Joe
>-----Original Message-----
>From: Nathan Scott [mailto:nathans@xxxxxxxxxxxxxxxxxxxxxxxx]
>Sent: Tuesday, January 16, 2001 7:31 AM
>To: Davida, Joe; 'linux-xfs@xxxxxxxxxxx '
>Subject: Re: xfs block size
>
>
>hi Joe,
>
>On Jan 12, 1:24pm, Davida, Joe wrote:
>> Subject: xfs block size
>> Are there any plans to support 64K FS block
>> sizes?
>> How soon (ballpark date)?
>> In what version of Linux (2.4, 2.5...etc)?
>>
>
>Yes, there are plans - details are at:
>http://oss.sgi.com/projects/xfs/todos.html#_multiblocksize
>
>>From a conversation with Russell, he's predicted an eta of
>around 3 - 6 months from now (also saying that at the moment
>its not clear exactly what the solution will be and that
>there's plenty on his plate before getting onto this issue).
>
>We'd be looking at a 2.4.x+XFS tree I would imagine.
>
>cheers.
>
>--
>Nathan
>
|