前段時間寫乙個程式時遇到了開啟乙個大於4g的檔案的問題，我開始是用標準c函式fopen來開啟，在windows下跑沒有問題，但是移植到linux下時，卻出現開啟檔案錯誤，測試發現開啟小檔案沒有問題，這可能跟系統的處理有關，仔細一想，linux下不可能不支援大檔案啊，應該有別的介面，所以上網查了一下，好不容易查到乙個英文網頁講這個東西，叫lfs（large file support），linux的標準底層c庫（glibc2.2.3以上）實現了對大檔案的支援，並且專為定義了一套api，具體在linux下開啟大檔案的方法有以下三種：
１。編譯時使用「gcc -d_file_offset_bits=64」選項，這樣所有的檔案操作都會使 用64位來處理（也即大檔案處理）
２。define
_largefile_source 和
_largefile64_source，這樣可以直接使用lfs的 介面，如open64.
３。使用linux系統函式open, 並且在開啟檔案的引數中加入
o_largefile，即
open("filename", o_rdonly | o_largefile)
我用的是第三種，沒有問題。
linux大檔案問題
32位linux系統對檔案大小有個限制,最大只能達到2 31 1位元組,也就是2g,即使檔案系統支援更大的4000g的檔案.具體為啥有這個限制我也說不清.只是在做乙個資料庫的tpc h測試時發現的.上網找了幾個資料,彙總一下大檔案的解決之道.對於用c語言的api開啟的檔案,也就是用fopen con...
Linux最大檔案開啟數
在linux下有時會遇到socket file can t open so many files的問題。其實linux是有檔案控制代碼限制的，而且linux預設一般都是1024 阿里雲主機預設是65535 在生產環境中很容易到達這個值，因此這裡就會成為系統的瓶頸。使用ulimit a 或者 ulim...
Linux最大檔案開啟數
linux作業系統對乙個程序開啟的檔案控制代碼數量的限制 也包含開啟的套接字數量 臨時生效 ulimit shn 10000 其實ulimit 命令身是分軟限制和硬限制，加 h就是硬限制，加 s就是軟限制。預設顯示的是軟限制，如果執行ulimit 命令修改時沒有加上 h或 s，就是兩個引數一起改變。...