BSD FFS: Unix жүйелеріндегі файлдық жүйелердің тарихы мен дамуы

Кіріспе

Көптеген Unix және Unix-ке ұқсас операциялық жүйелерде қолданылатын файлдық жүйе, сондай-ақ кейбір Unix және BSD операциялық жүйелеріндегі файлдық жүйенің іске асылуы. BSD FFS-тің мақсаты – байланысты дерек блоктары мен метадеректерді бір цилиндрлік топта, ал ең жақсысы, каталогтың барлық мазмұнын (барлық файлдар үшін деректер мен метадеректерді) бір немесе жақын орналасқан цилиндрлік топта орналастыруға тырысу, осылайша каталогтың мазмұнын бүкіл дискіге шашыратудан туындаған фрагментацияны азайту. Суперблоктағы өнімділік параметрлерінің кейбіреулеріне жолдар мен секторлардың саны, дискінің айналу жылдамдығы, оқу басының жылдамдығы және жолдар арасындағы секторлардың сәйкестігі кіреді. Толықтай оңтайландырылған жүйеде оқу басы жақын жолдар арасында жылжуы мүмкін, ал дискінің айналуын күтіп, кезектесіп орналасқан жолдардан шашыраңқы секторларды оқуға болады. Дискілердің көлемі үлкендеген сайын сектор деңгейіндегі оңтайландыру ескірді (әсіресе сызықтық сектор нөмірлеуді және жол бойынша өзгеретін секторларды қолданған дискілер үшін). Үлкен дискілер мен үлкен файлдар пайда болғанда фрагменттелген оқулар үлкен мәселеге айналды. Бұған қарсы күресу үшін BSD бастапқыда файлдық жүйе блогының көлемін 4.0 BSD-де бір сектордан 1 КБ-қа дейін ұлғайтты; ал FFS-де файлдық жүйе блогының көлемін 1 КБ-тан 8 КБ-қа дейін ұлғайтты. Бұл бірнеше әсерге ие. Файлдың секторларының тізбектес болу ықтималдығы әлдеқайда артады. Файлдың блоктарын тізімдеуге кеткен қосымша шығындар азаяды, ал белгілі бір блоктар санымен бейнеленетін байттардың саны көбейеді. Дискілердің үлкен көлемі де мүмкін болады, өйткені блоктардың максималды саны белгілі бір бит енімен шектеледі. Алайда, үлкен блоктармен көптеген кішкентай файлдары бар дискілер орынды ысыраптайды, өйткені әрбір файл кем дегенде бір блокты алуы керек. Осыған байланысты BSD блок деңгейіндегі фрагментацияны енгізді, сондай-ақ блоктардың қосалқы бөлуі, құйрық біріктіруі немесе құйрық жинағы деп те аталады, онда бірнеше файлдардан алынған соңғы толық емес дерек блогы бірнеше бос блоктардың орнына бір «фрагмент» блогында сақталуы мүмкін. Беркли FFS бойынша жұмыс басқа Unix өндірушілерімен кеңінен қабылданды, ал одан туындаған файлдық жүйелер отбасы UFS деп белгілі.

File system used by many Unix and Unix like operating systems
the file system implementation in some Unix and BSD operating systems

The intent of BSD FFS is to try to localize associated data blocks and metadata in the same cylinder group and, ideally, all of the contents of a directory (both data and metadata for all the files) in the same or nearby cylinder group, thus reducing fragmentation caused by scattering a directory's contents over a whole disk. Some of the performance parameters in the superblock included number of tracks and sectors, disk rotation speed, head speed, and alignment of the sectors between tracks. In a fully optimized system, the head could be moved between close tracks to read scattered sectors from alternating tracks while waiting for the platter to spin around. As disks grew larger and larger, sector level optimization became obsolete (especially with disks that used linear sector numbering and variable sectors per track). With larger disks and larger files, fragmented reads became more of a problem. To combat this, BSD originally increased the filesystem block size from one sector to 1 K in 4.0 BSD; and, in FFS, increased the filesystem block size from 1 K to 8 K. This has several effects. The chance of a file's sectors being contiguous is much greater. The amount of overhead to list the file's blocks is reduced, while the number of bytes representable by any given number of blocks is increased. Larger disk sizes are also possible, since the maximum number of blocks is limited by a fixed bit width block number. However, with larger block sizes, disks with many small files will waste space, since each file must occupy at least one block. Because of this, BSD added block level fragmentation, also called block suballocation, tail merging, or tail packing, where the last partial block of data from several files may be stored in a single "fragment" block instead of multiple mostly empty blocks. The work on Berkeley FFS was widely adopted by other Unix vendors, and the family of filesystems derived from it are collectively known as UFS.

Қолданылу

SunOS / Solaris, System V Release 4, HP UX және Tru64 UNIX сияқты кейбір меншік Unix жүйелерінің және illumos сияқты ашық Unix туынды жүйелерінің жеткізушілері UFS-ті қабылдады. Олардың көпшілігі UFS-ті өздерінің мақсаттарына бейімдеп, басқа сатушылардың Unix нұсқалары танымауы мүмкін меншік кеңейтулерін қосты. Көптегендер бастапқы блок өлшемін және деректер өрісінің енін бастапқы UFS ретінде пайдалануды жалғастырды, сондықтан платформалар арасында оқуға үйлесімділік белгілі бір дәрежеде сақталады. Жалпы алғанда, іске асырулардың үйлесімділігі нашар. Solaris 7-ден бастап Sun Microsystems UFS Logging-ті енгізді, ол UFS-ке файлдық жүйенің журналын қосты, ол әлі күнге дейін Solaris және illumos-тың қазіргі нұсқаларында бар. Solaris UFS-те үлкен файлдар мен үлкен дискілер үшін кеңейтулер және басқа да мүмкіндіктер бар. 4.4BSD және одан алынған BSD Unix жүйелерінде, мысалы FreeBSD, NetBSD, OpenBSD және DragonFlyBSD, UFS1 және UFS2 іске асыру екі қабатқа бөлінеді: жоғарғы қабат каталог құрылымын қамтамасыз етеді және метадеректерді қолдайды (рұқсаттар, меншік және т.б.) inode құрылымында, ал төменгі қабаттар inode ретінде іске асырылған деректер контейнерлерін қамтамасыз етеді. Бұл дәстүрлі FFS және LFS журналды құрылымдалған файл жүйесін ортақ функциялар үшін ортақ кодпен қолдау үшін жасалды. Жоғарғы қабат "UFS", ал төменгі қабаттар "FFS" және "LFS" деп аталады. Осы жүйелердің кейбіреулерінде "FFS" термині FFS төменгі қабаты мен UFS жоғарғы қабатының комбинациясына қолданылады, ал "LFS" термині LFS төменгі қабаты мен UFS жоғарғы қабатының комбинациясына қолданылады. Кирк Маккусик блоктарды қайта бөлуді іске асырды, бұл файл жүйесіндегі блоктар жазулар аяқталғанға дейін қайта реттеп, фрагментацияны азайту және файл жүйесінің ескіруін бақылау үшін. Ол сонымен қатар файл жүйесінің тұрақтылығын сақтайтын, бірақ өнімділікті дәстүрлі синхрондау режимінде шектемейтін жұмсақ жаңартуларды енгізді. Бұл файл жүйесін апат немесе электр қуатының бұзылуынан кейін тексеруді азайтады. Ақаудан кейін қалған мәселелерді шешу үшін fsck пайдалы бағдарламасы енгізілді. UFS2-де Кирк Маккусик пен Пол Хеннинг Камп FreeBSD FFS және UFS қабаттарын 64 биттік блок сілтемелерін (көлемдерді 8 зебибайтқа дейін өсіруге мүмкіндік береді), өзгермелі өлшемді блоктарды (шығарылымдарға ұқсас), кеңейтілген жалаушалар өрістерін, қосымша "туған күн" мөртабандарын, кеңейтілген атрибуттарды қолдауды және POSIX1 ACL-дарын қосу үшін кеңейтті. UFS2 FreeBSD 5.0-ден бастап қолдайтын UFS нұсқасы болды. FreeBSD сонымен қатар UFS1 және UFS2 үшін файл жүйесінің снэпшоттарын жасау мүмкіндігімен қатар, жұмсақ жаңартуларды енгізді. Бұл NetBSD-ге көшірілді, бірақ ақыр соңында жұмсақ жаңартулар (NetBSD-дегі жұмсақ тәуелділіктер деп аталады) NetBSD 6.0-ден WAPBL деп аталатын (одан әрі журналға жазу деп аталады) файл жүйесін журналға жазудың күрделі емес механизмі пайдасына алынып тасталды, ол NetBSD 5.0-де FFS-ке қосылды. OpenBSD 2.9 нұсқасынан бастап жұмсақ жаңартуларды қолдайды және 4.2 нұсқасынан бастап UFS2 (FFS2) қолдауы бар (ACL жоқ). OpenBSD қазір UFS2 UFS-тің әдеттегі нұсқасын жасады және 6.7 нұсқасына қосылады. FreeBSD 7.0-ден бастап UFS файл жүйесі GEOM провайдерін пайдалану арқылы журналға жазуды қолдайды. FreeBSD 9.0 бағдарламасында жұмсақ жаңартулар (SU+J) үстінде жеңіл журнал жазуға қолдау қосылды, бұл фондық fsck және NFSv4 ACL қажеттілігін едәуір азайтады. FreeBSD, NetBSD, OpenBSD және DragonFly BSD-де Иан Доузи әзірлеген Dirhash жүйесі бар. Бұл жүйе каталогтарды жылдам іздеу үшін жадыда хэш-кесте жасайды. Dirhash UFS-тегі үлкен каталогтармен байланысты бірқатар өнімділік мәселелерін жеңілдетеді. Linux-та UFS-ті басқа Unix-термен оқу деңгейінде үйлесімділік үшін енгізу бар, бірақ UFS-ке жеткізуші кеңейтулері үшін стандартты енгізу болмағандықтан, Linux-та UFS-ке жазу үшін толық қолдау жоқ. Туған Linux ext2 файл жүйесі UFS1-ден шықты, бірақ фрагменттерді қолдамайды және жұмсақ жаңартуларды енгізу жоспарланбаған. (Бірнеше 4.4BSD-ден алынған жүйелерде UFS қабаты ext2 қабатын контейнер қабаты ретінде пайдалана алады, дәл FFS және LFS пайдаланатыны сияқты.) NeXTStep, ол BSD-ден алынған, сонымен қатар UFS нұсқасын қолданды. Apple-дің Mac OS X-інде HFS+, олардың меншік файл жүйесіне балама ретінде қол жетімді болды. Алайда Mac OS X Leopard-тан бастап Mac OS X-ті UFS пішіміндегі томға орнату мүмкін емес болды. Сонымен қатар, UFS пішімделген томдарға орнатылған Mac OS X-тің ескі нұсқаларын Leopard-қа жаңарта алмайсыз; жаңарту үшін бастау томын қайта пішімдеу қажет. Mac OS X-те UFS форматталған дискілер үшін 4 ГБ файл шектелген. Mac OS X Lion-нан бастап UFS қолдау толығымен тоқтатылды.

Vendors of some proprietary Unix systems, such as SunOS / Solaris, System V Release 4, HP UX, and Tru64 UNIX, and open Unix derived systems like illumos, have adopted UFS. Most of them adapted UFS to their own uses, adding proprietary extensions that may not be recognized by other vendors' versions of Unix. Many have continued to use the original block size and data field widths as the original UFS, so some degree of read compatibility remains across platforms. Compatibility between implementations as a whole is spotty at best. As of Solaris 7, Sun Microsystems included UFS Logging, which brought filesystem journaling to UFS, which is still available in current versions of Solaris and illumos. Solaris UFS also has extensions for large files and large disks and other features. In 4.4BSD and BSD Unix systems derived from it, such as FreeBSD, NetBSD, OpenBSD, and DragonFlyBSD, the implementation of UFS1 and UFS2 is split into two layers: an upper layer that provides the directory structure and supports metadata (permissions, ownership, etc.) in the inode structure, and lower layers that provide data containers implemented as inodes. This was done to support both the traditional FFS and the LFS log structured file system with shared code for common functions. The upper layer is called "UFS", and the lower layers are called "FFS" and "LFS". In some of those systems, the term "FFS" is used for the combination of the FFS lower layer and the UFS upper layer, and the term "LFS" is used for the combination of the LFS lower layer and the UFS upper layer. Kirk McKusick implemented block reallocation, a technique that reorders the blocks in the file system just before the writes are done to reduce fragmentation and control file system aging. He also implemented soft updates, a mechanism that maintains the file system consistency without limiting the performance in the way the traditional sync mode did. This has the side effect of reducing the requirement of file system checking after a crash or power failure. To overcome the remaining issues after a failure, a background fsck utility was introduced. In UFS2, Kirk McKusick and Poul Henning Kamp extended the FreeBSD FFS and UFS layers to add 64 bit block pointers (allowing volumes to grow up to 8 zebibytes), variable sized blocks (similar to extents), extended flag fields, additional 'birthtime' stamps, extended attribute support and POSIX1. e ACLs. UFS2 became the supported UFS version starting with FreeBSD 5.0. FreeBSD also introduced soft updates and the ability to make file system snapshots for both UFS1 and UFS2. These have since been ported to NetBSD, but eventually soft updates (called soft dependencies in NetBSD) was removed from NetBSD 6.0 in favor of the less complex file system journaling mechanism called WAPBL (also referred as logging), which was added to FFS in NetBSD 5.0. OpenBSD has supported soft updates since version 2.9 and has had UFS2 (FFS2) support (no ACLs) since version 4.2. OpenBSD has now made UFS2 the default UFS version and will be included with the 6.7 release. Since FreeBSD 7.0, UFS also supports filesystem journaling using the gjournal GEOM provider. FreeBSD 9.0 adds support for lightweight journaling on top of soft updates (SU+J), which greatly reduces the need for background fsck, and NFSv4 ACLs. FreeBSD, NetBSD, OpenBSD, and DragonFly BSD also include the Dirhash system, developed by Ian Dowse. This system maintains an in memory hash table to speed up directory lookups. Dirhash alleviates a number of performance problems associated with large directories in UFS. Linux includes a UFS implementation for binary compatibility at the read level with other Unixes, but since there is no standard implementation for the vendor extensions to UFS, Linux does not have full support for writing to UFS. The native Linux ext2 filesystem was inspired by UFS1 but does not support fragments and there are no plans to implement soft updates. (In some 4.4BSD derived systems, the UFS layer can use an ext2 layer as a container layer, just as it can use FFS and LFS.) NeXTStep, which was BSD derived, also used a version of UFS. In Apple's Mac OS X, it was available as an alternative to HFS+, their proprietary filesystem. However, as of Mac OS X Leopard, it was no longer possible to install Mac OS X on a UFS formatted volume. In addition, one cannot upgrade older versions of Mac OS X installed on UFS formatted volumes to Leopard; upgrading requires reformatting the startup volume. There was a 4 GB file limit for disks formatted as UFS in Mac OS X. As of Mac OS X Lion, UFS support was completely dropped.