Для падтрымкі файлаў памерам больш за 2 Гб на 32-бітных сістэм, напрыклад x86, PowerPC і MIPS, шэраг змяненняў у ядры і C бібліятэкі павінна было быць зроблена. Гэта называецца Падтрымка вялікіх файлаў (ОРС). Падтрымка LFS павінна быць поўнай у цяперашні час у Linux і гэтая артыкул павінна даць кароткі агляд бягучага стану.
64-бітныя сістэмы, такія як Alpha, IA64 і x86-64 няма праблем з вялікімі файламі, але не падтрымліваюць новыя інтэрфейсы. У гэтым выпадку новы інтэрфейс у асноўным псеўданім звычайны інтэрфейс.
Падтрымка LFS робіцца Linux ядра і GNU C бібліятэка (ака Glibc).
LFS павышае мяжа максімальнага памеру файла. Для 32-бітных сістэм мяжа складае 2 31 (2 Гб), але з выкарыстаннем інтэрфейсу ОРС ў файлавых сістэмах, якія падтрымліваюць ОРС прыкладанні могуць працаваць з файламі памерам да 2 63 байт.
Для 64-бітных сістэм максімальнага памеру файла ў 2 63 байт, калі файлавая сістэма (напрыклад, NFSv2) падтрымлівае толькі менш.
Інтэрфейс ОРС ў Glibc 2.1.3 завершана, - але рэалізацыі няма. Рэалізацыі ў 2.1.3 змяшчае таксама некаторыя памылкі, напрыклад, ftello64 парушаецца. Калі вы хочаце выкарыстоўваць інтэрфейс LFS, вам трэба выкарыстоўваць Glibc, які быў складзены на загалоўкі ядра з падтрымкай LFS ў ім.
З Glibc 2.1.3 быў выпушчаны да LFS падтрымкі увайшоў у Linux 2.3.X/2.4.0-testX, некаторыя выпраўленні павінны былі быць зроблены, каб Glibc для падтрымкі ядра працэдур. Бягучай стабільнай версіі Glibc з'яўляецца Glibc 2.2.3 (2.2 быў выпушчаны ў лістападзе 2000 г.) і ён падтрымлівае ўсе функцыі ад Linux 2.4.0. Glibc версіі 2.2.x ў цяперашні час выкарыстоўваецца ў большасці асноўных дыстрыбутываў у сваёй апошняй версіі (напрыклад, SuSE 07/02, Red Hat 7.1). Glibc 02/02 падтрымлівае наступныя функцыі, Glibc 2.1.3 не падтрымлівае:
Праграмы, сабраныя супраць Glibc 2.1.3 будзе працаваць на сістэме LFS, няма неабходнасці ў перакампілявання праграм (за выключэннем 64-бітны Fcntl блакіроўкі). Толькі Glibc павінна быць абноўлены для падтрымкі LFS.
Звярніце ўвагу, што Glibc 2.0 і libc5 не падтрымліваюць ОРС на ўсіх.
Блакаванне праз Fcntl / lockf не працуе з вялікімі файламі ў Glibc 2.1.3. Дададзеная падтрымка ў Linux 2.4.0-test7 для ядра і неабходных несумяшчальныя змены ў Glibc, толькі 2,2 Glibc робіць з імі справіцца. Гэта азначае:
Так як Linux 2.4.0-test7 большасць інтэрфейс ядра ўваходзіць у ядро. Адкрытыя праблемы і абмежаванні апісаны ніжэй.
Мы можам вылучыць два ўзроўня адпаведнасці LFS ў файлавыя сістэмы:
Па крайняй меры, другога ўзроўню павінны, як правіла даступны, але некаторыя працы правесці аўдыт ўсіх дзіўных файлавых сістэм.
Некаторыя памылкі ў дачыненні да NFSv2 (2) былі зафіксаваныя ўжо, але некаторыя з іх адсутнічае (як O_LARGEFILE чэк). Іншыя файлавыя сістэмы, верагодна, не прапусціце гэта занадта. Поўны аўдыт ўсіх файлавых сістэм не патрабуецца (гл. таксама ядра 2.4 TODO старонцы http://linux24.sourceforge.net/).
Сітуацыя аб розных файлавых сістэм, якія выкарыстоўваюцца ў Linux 2.4.0 і больш позніх можна рэзюмаваць наступным чынам:
Калі файлы> 2 Гб ствараюцца ў ext2 старых ядрах будзе мантаваць файлавыя сістэмы толькі для чытання (яно устанаўлівае толькі для чытання сцяга сумяшчальнасці).
Крыс Мэйсан пісаў:
Дыскі адфарматаваны з бягучых 2,2 код называюць наш дыск фармату 3,5. Яны не будуць падтрымліваць вялікія файлы ў любы ядро (нават 2,4 код).
Але, вы можаце змантаваць дыск фармату 3,5 пры 2,4 код ядра, а таксама выкарыстоўваць -о умоўных. Гэта дазволіць ўключыць падтрымку вялікіх файлаў для старых дыскаў, але толькі новыя файлы будзе дазволена расці апошнія 2 Гб.
Як толькі вы ўсталёўваеце з -о умоўных, вы не можаце мантавання ў 2,2 больш. Мы тэстуем назад порт фармаце LFS дыск да 2,2, ён павінен быць гатовы ў бліжэйшы час. Ён мае тыя ж -о умоўных опцыя мантавання, што нашы 2,4 код, так што ўсе тыя ж правілы будуць прымяняцца.
Ядро Linux не падтрымлівае 64-бітныя rlimit сістэмны выклік тым не менш, Glibc падтрымлівае getrlimit64 і setrlimit64 але абкручванні занадта вялікія значэння RLIMIT_INFINITY.
Для выкарыстання ОРС у карыстацкія праграмы, праграмы павінны выкарыстоўваць LFS API. Гэта ўключае ў перакампілявання і змены праграм. API апісана ў Glibc кіраўніцтва (Libc старонак інфармацыі), якія можна чытаць, напрыклад, з "інфа Libc".
У двух словах для выкарыстання LFS вы можаце выбраць любую з наступных дзеянняў:
Поўнай дакументацыі асаблівасць тэсту макрасаў, як _FILE_OFFSET_BITS і _LARGEFILE_SOURCE ў Glibc кіраўніцтва (напрыклад, запусціць "Інфармацыя Libc" Функцыя Макрасы Test '").
LFS API таксама апісаны ў стандартным LFS які даступны па адрасе http://ftp.sas.com/standards/large.file/x_open.20Mar96.html.
Будзьце асцярожныя пры выкарыстанні _FILE_OFFSET_BITS = 64 для кампіляцыі праграмы, якая выклікае бібліятэку ці бібліятэку, калі любы з інтэрфейсаў выкарыстоўваецца off_t. З _FILE_OFFSET_BITS = 64 Glibc будзе змяніць тып off_t да off64_t. Вы можаце альбо змяніць інтэрфейс, каб заўсёды выкарыстоўваць off64_t, выкарыстоўваць розныя функцыі, калі _FILE_OFFSET_BITS = 64 выкарыстоўваецца (напрыклад, Glibc робіць). У адваротным выпадку паклапаціцца аб тым, як бібліятэкі і праграмы маюць тыя ж _FILE_OFFSET_BITS абстаноўцы. Звярніце ўвагу, што Glibc ўсведамляе _FILE_OFFSET_BITS налады, няма ніякай праблемы з ім, але могуць быць праблемы з іншымі бібліятэкамі.
Release 7.0 ад SuSE Linux падтрымлівае LFS на ўсіх падтрымоўваных платформах. Ядро SuSE 7.0 заснаваны на Linux 2.2.16.
Падтрымка ОРС ў SuSE Linux ядра такая ж, як у распрацоўцы ядра 2.4.0-test1 для файлавых сістэм, якія знаходзяцца ў абодвух ядраў, Glibc падтрымлівае ўсе функцыі ядра. Розныя файлавыя сістэмы ReiserFS (пакуль толькі ў SuSE, 2,2 порт не падтрымлівае ОРС) і NFSv3 (не даступны ў SuSE 7.0). Гэта азначае, што вам трэба выкарыстоўваць як ext2 файлавай сістэмы для LFS.
І Linux 2.4.0-test1 і SuSE 7.0 не падтрымліваюць getdents64 сістэмных выклікаў і 64-бітны інтэрфейс блакавання. Гэта толькі рэалізаваны ў Linux 2.4.0-test8 і навей.
Рэліз 07/01 SuSE Linux падтрымлівае LFS на ўсіх падтрымоўваных платформах. SuSE 07/01 пастаўляецца з ядром на аснове 2.4.0 і 2.2.18.
2.2.18 ядро падтрымка LFS з файлавай сістэмы ext2. 2.4.0 ядро падтрымлівае LFS з ext2 і NFSv3 файлавыя сістэмы і дадаткова з файлавай сістэмай ReiserFS, калі новы фармат ReiserFS (несумяшчальная з фарматам 2,2) выкарыстоўваецца замест стандартнага 2,2 фармаце.
SuSE 07/01 пастаўляецца з Glibc 2.2, падтрымлівае поўны інтэрфейс ОРС. Але ядро 2.2.18 толькі не падтрымлівае 64-разрадныя filelocking і getdents64 званкі.
Ядро падтрымка ОРС з'яўляецца, як у 7.1.
Паколькі я не магу праверыць кожнага размеркавання, я павінен давяраць іншым на наступную інфармацыю.
Бягучая стабільная версія (Debian 3.0, кодавае назву "драўняныя") мае LFS падтрымкі.
Бэта называецца Фішэр быў першым, хто LFS падтрымкі (дзякуючы Русі Маршал). Бягучы Чырвонай рэлізы Hat, як Red Hat 8 маюць LFS падтрымкі.
Цім Малыя
"οПтο ', якая ўбудаваная ў баш 1.x (па змаўчанні для Red Hat 6.2) выкарыстоўвае 32-бітныя версіі сістэмных выклікаў. Такім чынам, што ў цяперашні час вядзе сябе Glibc азначае, што запыты на 32 setrlimit або getrlimit будзе перакладаць «неабмежаваны» у '2 31 - 1 "у абодвух напрамках (я б сказаў, што ўстанаўленне мяжы RLIM_INFINITY выкарыстанні 32-бітнага інтэрфейсу павінны ў канчатковым выніку ў Выклік 64 варыянт setrlimit біт з 64 RLIM_INFITIY біт).
Стандартная канфігурацыя PAM для SSHD (/ і г.д. / pam.d / SSHD), уключае ў сябе лініі:
session required /lib/security/pam_limits.so
Якія скрыпкі аб розных межаў (з выкарыстаннем 32-бітных версій выклікаў).
Калі вы ўваходзіце ў выкарыстанні SSH, а таксама выкарыстоўваць баш 1.x, каб паглядзець у межах, вам будзе сказана, што памер файла не абмежаваны, калі гэта на самай справе ўстаноўлена ў 2.097.151 (1024 байт) блокаў!
Абыходны шлях:
У мяне няма якой-небудзь іншай інфармацыі пакуль няма. Вы можаце адправіць мне падрабязная інфармацыя аб дыстрыбутывах, калі яны падтрымліваюць ОРС.
Калі ласка, дашліце мне інфармацыю, запоўніць якія адсутнічаюць біты.
| Файлавая сістэма | Максімальнага памеру файла | Файлавая сістэма Size Limit |
|---|---|---|
| ext2/ext3 з 1 КБ блока | 16448 Мб (~ 16 Гб) | 2048 Гб (= 2 TiB) |
| ext2 / 3 з 2 КБ блока | 256 Гб | 8192 Гб (= 8 TiB) |
| ext2 / 3 з 4 КБ блока | 2048 Гб (= 2 TiB) | 8192 Гб (= 8 TiB) |
| ext2 / 3 з 8 КБ блока (сістэмы з 8 старонак КБ, як Альфа толькі) | 65568 Гб (~ 64 TiB) | 32768 Гб (= 32 TiB) |
| ReiserFS 3,5 | 2 Гб | 16384 Гб (= 16 TiB) |
| ReiserFS 3.6 (як і ў Linux 2.4) | 1 EIB | 16384 Гб (= 16 TiB) |
| XFS | 8 EIB | 8 EIB |
| JFS з 512 байт блока | 8 EIB | 512 TiB |
| JFS з 4KiB блока | 8 EIB | 4 ПοБ |
| NFSv2 (на баку кліента) | 2 Гб | 8 EIB |
| NFSv3 (на баку кліента) | 8 EIB | 8 EIB |
Заўвага ядра Абмежаванні: У прыведзенай вышэй табліцы апісваюцца абмежаванні на дыску фармату. Наступных межах ядра існуюць:
Звярніце ўвагу, у прыведзеным вышэй: 1024 байт = 1 КБ; 1024 КБ = 1 Мб; 1024 Мб = 1 Гб; 1024 Гб = 1 TiB; 1024 TiB = 1 ПοБ; 1024 ПοБ = 1 EIB (праверце http://physics.nist. GOV / Cuu / Адзінкі / binary.html)
Дыск IDE мае 64 непаўналетніх, з іх выкарыстоўваецца для поўнага дыска і, такім чынам, 63 раздзелаў магчымыя. SCSI дыск мае 16 непаўналетніх, і таму толькі 15 раздзелаў максімальная.
Дзякуючы Эндзі Клін, Маці Аарнио, Rogier Wolff, Крыс Мэйсан, Андрэас Шваб, Ленц Гриммер, Андриеш Брауэр, гарадскі Видмарк, Брус Ален і Яна Jaeger для дапаўненні і заўвагі па змесце гэтай старонкі.