Content deleted Content added
Matthiaspaul (talk | contribs) improved refs |
→Related problems: (translated) |
||
Line 23:
Except for [[embedded systems]] with their special programs, the consideration of varying large-file support becomes obsolete in program code after 2020.
== Related Problems ==
The [[year 2038 problem]] is well known for another case where a 32-bit "long" on 32-bit platforms will lead into problems. Just like the large-file limitation it will get obsolete when systems move to 64-bit only. In the meantime a 64-bit timestamp was introduced. In the Win32 API it is visible in functions having a "64" suffix along the earlier "32" suffix. When large-file support was added to the Win32 API it has lead to functions having an additional "i64" suffix which sometimes makes for four combinations.(findfirst32, findfirst64, findfirst32i64, findfirst64i32).<ref>{{cite web|url=https://docs.microsoft.com/de-de/cpp/c-runtime-library/reference/findfirst-functions?view=vs-2019|title=CTF Funktionsreferenz findfirst|publisher=Microsoft|accessdate=20200210}}</ref> By comparison the UNIX98 API introduces functions with a "64" suffix when "_LARGEFILE64_SOURCE" is used.
Related to the large-file API there is a limitation of block numbers for [[mass storage]] media. With a common size of 512 bytes per [[Block (data storage)|data block]] the barrier resulting from 32-bit numbers did occur later. When [[hard disk drive]]s reached a size of 2 terabyte (around 2010) the [[master boot record]] had to be replaced by the [[GUID Partition Table]] which uses 64-bit for the LBA numbers ([[logical block addressing|logical block address]]). On [[Unix-like]] operating systems it did also require to enlarge the [[inode]] numbers which are used in some functions (stat64, setrlimit64). The [[Linux kernel]] introduced that in 2001 leading to version 2.4 which was picked up by the glic in that year.<ref name=lfs>{{cite web|url=https://users.suse.com/~aj/linux_lfs.html|title=Large File Support in Linux|publisher=SUSE GmbH|date=2015-02-15|author=Andreas Jaeger}}</ref> As the large-file support and large-disk support was introduced at the same time the [[GNU C Library]] exports 64-bit inode structures on 32-bit architectures at the same time when the Unix LFS API is activated in program code.<ref>linux/bits/stat.h: /* Note stat64 has the same shape as stat for x86-64. */ </ref>
When the kernel moved to 64-bit inodes the file system [[ext3]] used them internally in the driver by 2001. However the inode format on the storage media itself was stuck at 32-bit numbers.<ref name=lfs /> As mass storage devices moved to the [[Advanced Format]] of 4 kilobyte per block the actual limit of that file system format is at 8 or 16 terabyte.<ref name=lfs /> Handling larger disk partitions requires the usage of a different file system like [[XFS]] which was designed with 64-bit inodes from the start allowing for exabyte files and partitions.<ref>{{cite web|url=https://www.mjr19.org.uk/sw/inodes64.html|title=The 64 bit inode problem|author=MJ Rutter|accessdate=2020-02-10}}</ref><ref>{{cite web|url=https://ext4.wiki.kernel.org/index.php/Ext4_Howto|title=Ext4 Howto|publisher=kernel.org|date=2019-02-11|quote=Although very large fileystems are on ext4's feature list, current e2fsprogs currently still limits the filesystem size to 2^32 blocks (16TiB for a 4KiB block filesystem). Allowing filesystems larger than 16T is one of the very next high-priority features to complete for ext4.}}</ref> The first 16 terabyte magnetic disk drives were delived by mid 2019. [[Solid-state drive]] with 32 TiB for data centers were available as early as 2016 with some manufacturers forcasting 100 TiB SSD by 2020.<ref>{{cite web|url=https://www.elektormagazine.de/news/samsungs-32-tb-ssd-der-anfang-vom-ende-der-festplatte|title=Samsungs 32-TB-SSD: Der Anfang vom Ende der Festplatte|publisher=Elektor|date=2016-08-15|author=Thomas Scherer}}</ref>
==See also==
| |||