Masopust Christian wrote:
hello rick,
Hi! At the risk of starting another flame war, Christian, we prefer
bottom-posting here on the list.
first thanks a lot for this detailed explaination!
You know me...I'm nothing if not bombastic! :-)
but (maybe stupid...), if it's possible to configure
the blocksize of my raid, it should be possible to access
greater raids than 2TB, right?
Uhm, hmmm. Good question. I've never tried it. I don't know if the
mkfs utilities query the block size of the device to set up their inode
tables or not (I'd have though that they'd have to). I suppose you
could give it a whirl and find out.
If you try it, let me know, willya? I don't have any equipment handy at
the moment that I can sacrifice for an experiment (all our equipment is
busy right now and all my money is tied up in debts!)
-----Ursprüngliche Nachricht-----
Von: fedora-list-bounces@xxxxxxxxxx
[mailto:fedora-list-bounces@xxxxxxxxxx] Im Auftrag von Rick Stevens
Gesendet: Montag, 04. April 2005 22:08
An: For users of Fedora Core releases
Betreff: Re: AW: RAID greater than 2TB on Fedora Core 3
Masopust Christian wrote:
>
> Hi Rick,
>
> is it really (nowadays??) a problem of SCSI-controler?
No, it's the SCSI protocol. SCSI allows 4 bytes (32 bits) to specify
the block number on a device, or 4,394,957,296 blocks. Given that most
disks use a 512-byte block, that's:
4,394,957,269 * 512 = 2,199,023,255,552 bytes
or 2TB. And before people jump on me, it's an unsigned 4-byte block
number. A signed value would make no sense--how do you access a
negative block number? I hear that the latest SCSI spec addresses this,
but I have no idea when (or if) it will be released and how long the
manufacturers will take to implement the new spec (if ever).
As an aside, the old 2GB file size limit was caused by using a signed
32-bit value as the second parameter in an lseek() (2^31 is
2,147,483,648, and that's in bytes--not blocks and it was signed to
allow you to seek backwards from the current postition).
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- To understand recursion, you must first understand recursion. -
----------------------------------------------------------------------
