0

What is the maximum file size limit in rhel 32 bit OS, is there any OS limitation for the file size , if there is any limitation set then please tell me what will be for root & oaa.

5

File size is limited by filesystem type not by OS. Typically, OS supports several filesystems, so there is no such thing like "OS file size limit". There are limits for well-known filesystems:

FAT32 - 4Gib  
NTFS - 16Eib  
ext2/3 - 16Gib - 2Tib (depends from block size)  
ext4 - 16Gib - 16Tib  
XFS - 9Eib  
ZFS - 16Eib
  • Hi Thanks for your reply, my requirement is i have file in 32 BIT rhel 5 and it gradually increases up to 1.5 GB in a day, in case if it reaches more than 4 GB ours guys says the process which is writting to a file will crash, says there is no limitation for 64 GB but in 32 GB it should not cross 4Gb, is it true what is the information provided to me ...? – vikram rao Apr 5 '16 at 10:19
  • 32bit OSes can use up to 4gb of RAM. It is not related to disk space. – user1700494 Apr 5 '16 at 11:02
  • 1
    Technically there is an OS file size limit: 2^64 bytes. But I don't know of any common filesystem that allows such large files, so the filesystem is the limiting factor. – Gilles 'SO- stop being evil' Apr 5 '16 at 23:33
  • 1
    @vikramrao The only reason why the process would crash is if it's badly written or extremely old. Not the fault of the OS. – Gilles 'SO- stop being evil' Apr 5 '16 at 23:34
  • @Gilles, At least ZFS would support it but in that case, the limit is more due to the hardware capacity to store such a large file. – jlliagre Apr 6 '16 at 10:49
2

Since more than a decade, 32 bit Linux applications are able to access files larger than 2 GiB (2^31) thanks to the implementation of large file support. The current OS limitation is 8 EiB (2^63) which shouldn't hit the common of us before a while...

You would need a file system that makes no lower limit on file size too.

  • 2
    2^31 bytes ~ 2 GiB not TiB – Bemipefe Nov 23 '17 at 14:12
0

Large File Support (LFS) is not supported by default on either:

  • 32 bit kernels
  • 32 bit processes running on 64 bit kernels.

As stated in the following post it should be explicitly enabled in the kernel at compilation time. Otherwise the file size is limited to 2147483647 bytes = 2^31 - 1 (1 byte is probably reserved for the kernel or FS).

  • If you have a 32 bit RHEL you can quickly verify that with the following command:

    dd if=/dev/zero of=./LargeFile bs=1024 count=3000000
    
  • If you have a 64 bit RHEL and the process is compiled for 32 bit systems you have the same problem. You can verify that by running the following program:

    #include <stdlib.h> 
    #include <stdio.h>
    #include <string.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>
    
    int main(int argc, char *argv[], char *envp[])
    {
        int result;
        long long to_write = 3000000000;
        int file_descriptor = open("LargeFile" , O_CREAT | O_RDWR , 0600);
        char chunk[1024];
    
        memset(chunk , 'A' , 1024);
    
        while(to_write > 0)
        { 
            result = write(file_descriptor , chunk , 1024);
    
            if(result != 1024)
            {
                printf("***ERROR*** %d\n" , result);
                break;
            }
    
            to_write -= 1024;
            usleep(200);
        }
    
        close(file_descriptor);
        return 0;
    }
    

You need to compile the program as 32 bit executable:

gcc -m32 -Wall -g main.c -o main

Both programs will stop before that the file reaches the size of 3 GB

  • truncate -s 10T is a quicker way to create a 10TiB large file. – Stéphane Chazelas Nov 23 '17 at 15:25
  • @Stéphane Chazelas Although I only wanted to attempt the creation of 3 GiB file I agree that using truncate can be quicker than using dd. – Bemipefe Nov 23 '17 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.