Joe Greco <[EMAIL PROTECTED]> wrote:
> >
> > Joe seem to want one. This size is certaintly within the reach of an
> > ISP now, and disks just keep getting bigger. My administrative bias is
> > that partitioning for a reason other then policy should be avoided and
> > thus I'd love to see filesystem size support keep ahead of volume sizes
> > where possiable. That said, unless someone gives me a very substantial
> > amount of money to build a cluster at work, I'm not going to be building
> > any TB file systems for a few more years.
>
> Well, I just wanted the thrill of it.
>
> I should be building additional machines throughout the year. If anyone is
> seriously interested in work on terabyte filesystem issues, I may be able
> to shanghai one for a month or two and provide access to it. I may even be
> able to push it over the 2TB mark (barely). I do not have the
> qualifications or need to be doing this myself, though, alas.
>
> 72GB disks will be available later this year. Expect 2.6TB servers. :-)
>
I will assert that it is insanity to build and use a 1TB UFS
for small files (~ 2.5e8 inodes or 32GB) at least with the current
technology. Maybe I am wrong, if anyone thinks so feel free to tell
me. Having said this I think that Matt's idea of increasing the
effective sector size may be way to go. Does this sound resonable to
everyone? I have my doubts about whether I could get something like
this done in finite time given my current schedule, but I wil begin
looking at it.
Matt,
Correct me if I am wrong, but the sector size is what has to
change, and not just the block size. This being true it would seem
that if we wanted 2048TB in a FS, we the minimum fragment size would
be 1MB (the virtual sector size) as there would be no way of
addressing anything smaller.
As a side note, would this cause big problems for the
VM system as suddenly it has to page to/from files in chunks of
256 pages? Or is this fairly well isolated in the code?
--John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message