Падтрымка вялікіх файлаў у Linux

Science for all





Original article: http://users.suse.com/~aj/linux_lfs.html

Падтрымка вялікіх файлаў у Linux

Для падтрымкі файлаў памерам больш за 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) падтрымлівае толькі менш.

LFS ў Glibc 2.1.3 і Glibc 2,2

Інтэрфейс ОРС ў 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 не падтрымлівае:

  • getdents64 сістэмны выклік
  • 64 біт блакавання файлаў інтэрфейсу (падрабязней гл ніжэй)

Праграмы, сабраныя супраць Glibc 2.1.3 будзе працаваць на сістэме LFS, няма неабходнасці ў перакампілявання праграм (за выключэннем 64-бітны Fcntl блакіроўкі). Толькі Glibc павінна быць абноўлены для падтрымкі LFS.

Звярніце ўвагу, што Glibc 2.0 і libc5 не падтрымліваюць ОРС на ўсіх.

Блакаванне на вялікіх файлах не падтрымліваецца Fcntl / lockf ў Glibc 2.1.x

Блакаванне праз Fcntl / lockf не працуе з вялікімі файламі ў Glibc 2.1.3. Дададзеная падтрымка ў Linux 2.4.0-test7 для ядра і неабходных несумяшчальныя змены ў Glibc, толькі 2,2 Glibc робіць з імі справіцца. Гэта азначае:

  • Вы не можаце выкарыстоўваць сцягі F_GETLK64, F_SETLK64 і F_SETLKW64 з Fcntl, калі вы выкарыстоўваеце Glibc 2.1.x. Калі вашы праграмы выкарыстоўваюць іх цяпер, яны не могуць. Яны таксама патрабуюць перакампілявання з glibс 2,2, якія будуць падтрымліваць гэтыя Fcntl сцягі.
  • lockf64 працуе толькі з файламі <2 Гб з Glibc 2.1.x, гэта робіць працу з Glibc 2.2 і ня перакампілявання не патрабуецца.

ОРС у ядры Linux

Так як Linux 2.4.0-test7 большасць інтэрфейс ядра ўваходзіць у ядро. Адкрытыя праблемы і абмежаванні апісаны ніжэй.

Файлавыя сістэмы

Мы можам вылучыць два ўзроўня адпаведнасці LFS ў файлавыя сістэмы:

  1. Поўная падтрымка файлаў> 2 Гб і O_LARGEFILE
  2. Абмежаваная падтрымка LFS: ён дае правільны EINVAL / EFBIG / EOVERFLOW паведамленняў пра памылку пры спробе выкарыстоўваць O_LARGEFILE або пазіцыі> 2 Гб.

Па крайняй меры, другога ўзроўню павінны, як правіла даступны, але некаторыя працы правесці аўдыт ўсіх дзіўных файлавых сістэм.

Некаторыя памылкі ў дачыненні да NFSv2 (2) былі зафіксаваныя ўжо, але некаторыя з іх адсутнічае (як O_LARGEFILE чэк). Іншыя файлавыя сістэмы, верагодна, не прапусціце гэта занадта. Поўны аўдыт ўсіх файлавых сістэм не патрабуецца (гл. таксама ядра 2.4 TODO старонцы http://linux24.sourceforge.net/).

Сітуацыя аб розных файлавых сістэм, якія выкарыстоўваюцца ў Linux 2.4.0 і больш позніх можна рэзюмаваць наступным чынам:

ext2/ext3
Поўная падтрымка LFS
NFSv2
Не можа справіцца з LFS-за абмежаванняў пратаколу (абмежаваны 2 Гб - 1); абмежаваная падтрымка LFS але чакаць некаторыя памылкі
NFSv3
Пратакол у парадку, але я не ўпэўнены, аб ходзе ўкаранення сістэмы Linux
ReiserFS 3.5.x (не ўваходзіць у ядро, асобны патч)
Не падтрымлівае LFS
ReiserFS 3.6.x (частка ядра 2.4.1 і навей)
Поўная падтрымка LFS, калі новы фармат на дыск выкарыстоўваецца. Гэты фармат з'яўляецца несумяшчальным з фарматам, выкарыстоўваным 3.5.x (гл. ніжэй некалькі падрабязней).
кода
Не працуе з ОРС (мясцовыя праблемы кэша, пратакол у парадку)
UFS
Поўная падтрымка LFS (хоць і не поўным па параўнанні з O_LARGEFILE сцяг выкарыстання)
MINIX
абмежаваны 2 Гб - 1 (памер файла абмежаваны 65804 MiB але ўлічыце, што памер файлавай сістэмы абмежаваны 64 Мб, - але адтуліны не дапускаюцца)
SysV (ака ШАС)
абмежаваны 2 Гб -1
MSDOS
абмежаваны 2 ГБ - 1
UMSDOS
на аснове MS-DOS, абмежаваны 2 ГБ - 1
SMBFS
Старыя пратаколы абмежаваны 4 Гб - 1. SMB пашырэння дазваляюць файлавых 64 біт. Linux SMBFS рэалізацыі ў цяперашні час абмежаваны 2 Гб - 1.
NCPFS
пратакол абмежаваны 4 Гб - 1, Linux рэалізацыі да 2 ГБ - 1
JFS
Павінна працаваць з ОРС (падрабязней аб JFS бачыць http://oss.software.ibm.com/developer/opensource/jfs)
XFS
Павінна працаваць з ОРС (падрабязней пра XFS бачыць http://http://linux-xfs.sgi.com/projects/xfs/)
іншых файлавых сістэм
У мяне няма якой-небудзь інфармацыі пакуль няма, не саромейцеся, дасылайце мне абнаўлення.
Заўвага для ext2

Калі файлы> 2 Гб ствараюцца ў ext2 старых ядрах будзе мантаваць файлавыя сістэмы толькі для чытання (яно устанаўлівае толькі для чытання сцяга сумяшчальнасці).

Заўвага для ReiserFS

Крыс Мэйсан пісаў:

Дыскі адфарматаваны з бягучых 2,2 код называюць наш дыск фармату 3,5. Яны не будуць падтрымліваць вялікія файлы ў любы ядро ​​(нават 2,4 код).

Але, вы можаце змантаваць дыск фармату 3,5 пры 2,4 код ядра, а таксама выкарыстоўваць -о умоўных. Гэта дазволіць ўключыць падтрымку вялікіх файлаў для старых дыскаў, але толькі новыя файлы будзе дазволена расці апошнія 2 Гб.

Як толькі вы ўсталёўваеце з -о умоўных, вы не можаце мантавання ў 2,2 больш. Мы тэстуем назад порт фармаце LFS дыск да 2,2, ён павінен быць гатовы ў бліжэйшы час. Ён мае тыя ж -о умоўных опцыя мантавання, што нашы 2,4 код, так што ўсе тыя ж правілы будуць прымяняцца.

rlimit64 не падтрымліваецца

Ядро Linux не падтрымлівае 64-бітныя rlimit сістэмны выклік тым не менш, Glibc падтрымлівае getrlimit64 і setrlimit64 але абкручванні занадта вялікія значэння RLIMIT_INFINITY.

Выкарыстанне LFS

Для выкарыстання ОРС у карыстацкія праграмы, праграмы павінны выкарыстоўваць LFS API. Гэта ўключае ў перакампілявання і змены праграм. API апісана ў Glibc кіраўніцтва (Libc старонак інфармацыі), якія можна чытаць, напрыклад, з "інфа Libc".

У двух словах для выкарыстання LFS вы можаце выбраць любую з наступных дзеянняў:

  • Кампіляцыі вашых праграм з "GCC-D_FILE_OFFSET_BITS = 64". Гэта прымушае ўсіх доступу да файлаў званкоў выкарыстаць 64 варыянтаў няшмат. Некалькі відаў змены таксама, напрыклад, off_t становіцца off64_t. Таму важна, каб заўсёды выкарыстоўваць правільныя тыпы і не выкарыстоўваць, напрыклад, Int замест off_t. Для пераноснасці з іншымі платформамі вы павінны выкарыстоўваць getconf LFS_CFLAGS які верне -D_FILE_OFFSET_BITS = 64 на Linux платформах, але можа вярнуць што-небудзь іншае, напрыклад, на Solaris. Для спасылкі, вы павінны выкарыстоўваць спасылку сцягі, якія, як паведамляецца праз getconf LFS_LDFLAGS. У сістэмах Linux, вам не патрэбныя спецыяльныя сцягі спасылцы.
  • Вызначыць _LARGEFILE_SOURCE і _LARGEFILE64_SOURCE. З гэтымі вызначае Вы можаце выкарыстоўваць функцыі, такія як LFS Open64 напрамую.
  • Выкарыстоўвайце O_LARGEFILE сцяг з адкрытым для працы з вялікімі файламі.

Поўнай дакументацыі асаблівасць тэсту макрасаў, як _FILE_OFFSET_BITS і _LARGEFILE_SOURCE ў Glibc кіраўніцтва (напрыклад, запусціць "Інфармацыя Libc" Функцыя Макрасы Test '").

LFS API таксама апісаны ў стандартным LFS які даступны па адрасе http://ftp.sas.com/standards/large.file/x_open.20Mar96.html.

LFS і бібліятэкі, акрамя Glibc

Будзьце асцярожныя пры выкарыстанні _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 налады, няма ніякай праблемы з ім, але могуць быць праблемы з іншымі бібліятэкамі.

Размеркавання з падтрымкай LFS

SuSE 7.0

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 і навей.

SuSE 07/01

Рэліз 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 званкі.

SuSE 07/02 і навей

Ядро падтрымка ОРС з'яўляецца, як у 7.1.

Іншыя дыстрыбутывы

Паколькі я не магу праверыць кожнага размеркавання, я павінен давяраць іншым на наступную інфармацыю.

Debian

Бягучая стабільная версія (Debian 3.0, кодавае назву "драўняныя") мае LFS падтрымкі.

Red Hat

Бэта называецца Фішэр быў першым, хто 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 байт) блокаў!

Абыходны шлях:

  • Альбо:
    • Закомментируйте радок у / і г.д. / pam.d / SSHD (заўважым, што абмежаванні, устаноўленыя ў / і г.д. / бяспеку / limits.conf больш не будзе эфектыўным для SSH лагінаў)
    • Або: Rebuild пакет PAM з 64-бітнай падтрымкі
  • Усталюйце RPM bash2
  • Альбо:
    • перайменаваць стары баш, а сімвалічная спасылка / bin/bash2 у / BIN / Bash (вы можаце захаваць / бен / ш паказваючы на ​​стары баш, калі вы турбуецеся аб сумяшчальнасці)
    • Або: выкарыстоўвайце vipw змяніць карыстальнікі к / bin/bash2

Іншае...

У мяне няма якой-небудзь іншай інфармацыі пакуль няма. Вы можаце адправіць мне падрабязная інфармацыя аб дыстрыбутывах, калі яны падтрымліваюць ОРС.

Некаторыя іншыя Часта запытаныя дадзеныя аб файлавых сістэмах

Калі ласка, дашліце мне інфармацыю, запоўніць якія адсутнічаюць біты.

Максімальна на дыску Памеры Файлавыя сістэмы

Файлавая сістэма Максімальнага памеру файла Файлавая сістэма 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

Заўвага ядра Абмежаванні: У прыведзенай вышэй табліцы апісваюцца абмежаванні на дыску фармату. Наступных межах ядра існуюць:

  • На 32-бітных сістэмах з ядром 2.4.x: памер файла і блокавых прылад абмежаваны 2 TiB. Пры выкарыстанні LVM некалькі блокавых прылад могуць быць аб'яднаны дазваляюць апрацоўку вялікіх файлавых сістэм.
  • 64-разрадныя сістэмы: памер файлавай сістэмы і файла абмежаваны 2 63 (8 ЕІБ). Але можа быць драйвераў прылад абмежаванні, якія не дазваляюць атрымаць доступ да такім вялікім прылад.
  • Kernel 02/06: Для 32-разрадных сістэм з опцыяй CONFIG_LBD ўсталяваць і для 64-разрадных сістэм: памер файлавай сістэмы абмежаваны 2 73 (занадта шмат на сёння). На 32-бітных сістэм (без набору CONFIG_LBD) памер файла абмежаваны 2 TiB. Заўважым, што не ўсе файлавыя сістэмы і драйвераў прылад могуць апрацоўваць такія вялікія файлавыя сістэмы.

Звярніце ўвагу, у прыведзеным вышэй: 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 для дапаўненні і заўвагі па змесце гэтай старонкі.