DA Morgan wrote:
> Billy Verreynne wrote:
>
>
>>Frank wrote:
>>
>>
>>>Could some OS guru elaborate on why some OS's only handle 2GB?
>>>Seems to me these must be 31 bit then. (AIX 4.x had a special
>>>'add-on' to go beyond 2GB, looked like the MSB was enabled, so to speak)
>>
>>Won't call myself an OS guru, but I will have a bash (don't like ksh or csh
>>that much ;-).
>>
>>Firstly, it has _nothing_ to do with operating system and _everything_ to do
>>with the file system.
>>
>>And this type of problem has been around for a long while. Back in my
>>mainframe days, the filesystem used on the Siemens BS2000 o/s (still IMO
>>one of the best mainframe o/s's ever) used a single byte for storing extent
>>number. Thus you were limited to 255 extents. (wasn't this also the case
>>with Oracle extents a few versions ago?)
>>
>>Using DOS old FAT16 filesystem is no different. The File Allocation Table
>>has also size restrictions. Thus, a completed path of a subdirectory can
>>only be (if I recall correctly) also 255-256 characters in total. When you
>>reached that limit, you can not create any more subdirectories.
>>
>>Okay, now for ionodes and Unix. A file is represented by a structure called
>>an inode (similar to a FAT entry).
>>
>>Each inode contains stuff like file type, access rights, timestamps, size,
>>pointers to data blocks, and so on. A bunch of data blocks make up a file.
>>Their addresses are stored in that file's inode.
>>
>>An ionode is of a certain size. Thus, you are limited to the number of data
>>block pointers (or addresses) you can store in the ionode of a file.
>>
>>Here are a table listing Unix filesystems used by Linux through the years:
>> Minix ext ext2
>>Max fileystem size 64MB 2GB 4TB
>>Max file size 64MB 2GB 2GB
>>
>>Because operating systems are closely tied to specific filesystems (often
>>only running on a single specific filesystem), filesystem limitation such
>>as the 2GB filesize limit is seen as an operating system issue. Which is
>>not really the case as that limitation belongs solely to the filesystem.
>>
>>--
>>Billy
>
>
> You are correct but I don't see the separation as clearly as you do. If an O/S
> doesn't support a file system it is the O/S that is the issue.
>
> In the case of some O/Ss they default to 2GB files and default parameters in the
> O/S can be changed to allow larger files. The makes it look, again, like the O/S
> to me.
>
> Daniel Morgan
>
First of all - Billy is right in stating it is a file system issue, not
OS. I must become more precise...
And Daniel: what about Microsoft's 536MB "barrier", 2GB, 4GB, ...?
Doesn't MS have DOS (in two flavors, if I may believe the Linux
Installer/Disk Druid: FAT12/FAT16), NTFS, FAT32? Afaik, you can
still install Win2K on a DOS16 partition - it will effectively
limit your file (and partition!) sizes, but you can. You can also
migrate to NTFS of FAT32, allowing for much larger files/partitions.
OS/2 could use HPFS (superior to NTFS, in my opinion), or FAT.
I remember burning a special CD off the standard NT Server CD, with
drivers of sp4 (iirc), just because that allowed you to install
NT in a larger-than-2GB partition. Until sp4, you could not create
a boot partition, larger than 2GB.
Don't many of today's Linux distro's give you a choice of ext2,
ext3, reiserfs, journalled rfs, or a combination of all of the above?
If you still want to call it an OS issue, fine with me, but I hope
I have made it clear with the above examples, that it is more of
a file system issue.
OS's (even MS!) support multiple file systems; it's up to the user
to decide what's best.
--
Regards, Frank van Bortel
Received on Fri Feb 14 2003 - 14:01:12 CST
