https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-7592 Lustre <p>Currently attempts of creating ldisk file system with size &gt;128TB finished with message.</p> <p>LDISKFS-fs does not support file systems greater than 128TB and can cause data corruption.Use "force_over_128tb" mount option to override.</p> <p>Before using “force_over_128tb” parameter in production systems lustre file system software should be analyzed to point possible large disks support issues. This issue is about research of some aspects of Lustre software. Finally patch that change "force_over_128tb" to "force_over_256tb" should be landed. This gives ability use ldiskfs partitions &lt;256tb without options.</p> LU-7592

Сhange force_over_128tb lustre mount option to force_over_256b for ldiskfs

Improvement Major Resolved Fixed WC Triage Artem Blagodarenko patch Tue, 22 Dec 2015 08:19:33 +0000 Fri, 8 Dec 2017 15:36:32 +0000 Tue, 18 Apr 2017 17:40:57 +0000 Lustre 2.9.0 0 5 <p>Artem Blagodarenko (artem.blagodarenko@seagate.com) uploaded a new patch: <a href="http://review.whamcloud.com/17702" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/17702</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7592" title="Сhange force_over_128tb lustre mount option to force_over_256b for ldiskfs" class="issue-link" data-issue-key="LU-7592"><del>LU-7592</del></a> osd-ldiskfs: increase supported ldiskfs fs size limit<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 1bc3e656ae7096711c2ce6310234a81b989089b8</p> <p>Verification steps:<br/> 1. Lustre code check to verify it is ready for &lt;256TB targets<br/> 2. Testing </p> <p>Issues verified and tested:<br/> 1. Default ldiskfs parameters for command<br/> mkfs.lustre --ost --fsname=testfs --mountfsoptions='force_over_128tb' /dev/md1</p> <p>-J size=400 -I 256 -i 1048576 -q -O extents,uninit_bg,dir_nlink,huge_file,64bit,flex_bg -G 256 -E lazy_journal_init,lazy_itable_init=0 -F</p> <p>2 Inode count limitation <br/> There is inode count limitation check in mkfs utility (misc/mke2fs.c file) "num_inodes &gt; MAX_32_NUM"<br/> With current option -i 1048576 for 256 TB OST inode count is 256M that is less then 2^32 -1. Smallest bytes per node ratio for 256TB is 32769. If this parameter smaller than value is truncated by mkfs utility to maximum possible.<br/> <b>Case with with -i &lt; 32769 is successfully tested</b></p> <p>MDS required inodes count can be calculated. It has to be more than ost inode count * number of ost. This calculations for worst case with 1 stripe. With current option -i 1048576 for 256TB OST inode count is 256M. Maximum inodes count is 2^32-1=4294967296, so this limit is exceeded with 4294967296/256M=16 OSTs. <br/> Often this parameter for MDS smaller then default( -i 4096 for example)<br/> Such rate (-i 4096) can’t be used for 256TB disk, because exceeding of 4G inode. Currently, because of limitation of inodes count sometimes MDT can’t be used fully. Probably this is time for extending this limit (Should we add such task?).</p> <p>3. Directories format. 32 directories with 64kb files<br/> OST has 32 object directories. Each of them can store 64kb of files. Thus, the limit of files on OST is<br/> 65536 * 32 = 2097152 this. Such situation fixes option dir_nlink. The pieces of code that enable this option shown above:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> void ext4_inc_count(handle_t *handle, struct inode *inode) { inc_nlink(inode); <span class="code-keyword">if</span> (is_dx(inode) &amp;&amp; inode-&gt;i_nlink &gt; 1) { <span class="code-comment">/* limit is 16-bit i_links_count */</span> <span class="code-keyword">if</span> (inode-&gt;i_nlink &gt;= EXT4_LINK_MAX || inode-&gt;i_nlink == 2) { inode-&gt;i_nlink = 1; EXT4_SET_RO_COMPAT_FEATURE(inode-&gt;i_sb, EXT4_FEATURE_RO_COMPAT_DIR_NLINK); } } } /* * If a directory had nlink == 1, then we should let it be 1. This indicates * directory has &gt;LDISKFS_LINK_MAX subdirs. */ <span class="code-keyword">static</span> void ldiskfs_dec_count(handle_t *handle, struct inode *inode) { <span class="code-keyword">if</span> (!S_ISDIR(inode-&gt;i_mode) || inode-&gt;i_nlink &gt; 2) drop_nlink(inode); } </pre> </div></div> <p>There are some doubts how this code works when i_nlink become less then EXT4_LINK_MAX. There is sanity run_test 51b "exceed 64k subdirectory nlink limit" but it has some issues:<br/> a. It tests exceed 64k subdirectory on mds, but ost differ from mds (at least ost use vfs)<br/> b. Test doesn’t create 64k files<br/> The requirements for test improvement added to 3.1.3.<br/> Test case <br/> a. Create more than 64k files on ldiskfs partition<br/> b. Try to delete file so file count less than EXT4_LINK_MAX<br/> c. Force file system check with fsck (ost)<br/> <b>successfully tested</b></p> <p>4 Performance near first and last block of disk<br/> Due to large disk size some performance loss at the end of surface is possible. There are mkfs options that move some metadata to the start of disk (flex_bg and -G) . This options are used in some configuration, but numbers should be corrected. “-G 256” means that 256 block groups are allocated at the start of disk to store bitmaps and inode tables. This parameter can be adjusted for new size of disk. Patch that adds option "-G" in <a href="https://jira.whamcloud.com/browse/LU-6442" title="mkfs -G &lt;value&gt; parameter is not changed actually and default value is applied" class="issue-link" data-issue-key="LU-6442"><del>LU-6442</del></a> landed.</p> <p>5 ldiskfs data structures limitations<br/> 5.1 ext4_map_inode_page function's parameter blocks should be 64bit long<br/> There is function with parameter “unsigned long *blocks”: <br/> int ext4_map_inode_page(struct inode *inode, struct page *page,<br/> unsigned long *blocks, int create)</p> <p>But ext4_bmap returns sector_t value.</p> <p>static sector_t ext4_bmap(struct address_space *mapping, sector_t block)<br/> blocks<span class="error">&#91;i&#93;</span> = ext4_bmap(inode-&gt;i_mapping, iblock);</p> <p>That depending on macros can be 32 or 64 bit long<br/> /**</p> <ul> <li>The type used for indexing onto a disc or disc partition.<br/> *</li> <li>Linux always considers sectors to be 512 bytes long independently</li> <li>of the devices real block size.<br/> *</li> <li>blkcnt_t is th type of the inode's block count.<br/> */<br/> #ifdef CONFIG_LBDAF<br/> typedef u64 sector_t;<br/> typedef u64 blkcnt_t;<br/> #else<br/> typedef unsigned long sector_t;<br/> typedef unsigned long blkcnt_t;<br/> #endif</li> </ul> <blockquote> <p>CONFIG_LBDAF:Enable block devices or files of size 2TB and larger.This option is required to support the full capacity of large (2TB+) block devices, including RAID, disk, Network Block<br/> Device, Logical Volume Manager (LVM) and loopback.This option also enables support for single files larger than 2TB.The ext4 filesystem requires that this feature be enabled in order to support filesystems that have the huge_file feature enabled. Otherwise, it will refuse to mount in the read-write mode any filesystems that use the huge_file feature, which is enabled by default by mke2fs.ext4.The GFS2 filesystem also requires this feature.If unsure, say Y.</p></blockquote> <p>So we need to use sector_t for this array of blocks.<br/> The field dr_blocks in osd_iobuf and its users should be corrected.<br/> This fix is actual <b>for x86_32 systems only</b>, because unsigned long is 64bit long on x86_64 systems. Fix is uploaded to (<a href="https://jira.whamcloud.com/browse/LU-6464" title="ldiskfs: ext4_map_inode_page() ready for large blocks count" class="issue-link" data-issue-key="LU-6464"><del>LU-6464</del></a>, landed)</p> <p>6. Obdfilter. Block addressing etc.<br/> Nothing suspicious.</p> <p>7. Extended attribute inode probable overflow<br/> xattr store 32 bit inode number (as expected). <br/> __le32 e_value_inum; /* inode in which the value is stored */<br/> xattr inode’s blocks addressed using local block counters.</p> <p>8. Quta limits. Sizes and inodes.<br/> Nothing changed. 32 bit counters are used for inode addressing. Quotes are still ready for such counters.</p> <p>9. llog. llog id limitaions<br/> Llog subsystem uses llog_logid, that has ost_id type inside with 64bit types.</p> <p>10 Tools. FSCK - 64 bits block number<br/> There are 64 bit for addressing blocks by number.<br/> typedef __u64 __bitwise blk64_t;<br/> There is 32 bit version<br/> typedef __u32 __bitwise blk_t;</p> <p>1) It is used for bad blocks accessing in wrong way. There is patch that chagnes bad blocks numbers to 64bit <a href="http://patchwork.ozlabs.org/patch/279297/" class="external-link" target="_blank" rel="nofollow noopener">http://patchwork.ozlabs.org/patch/279297/</a> we could port it or make from scratch. (LU-XXXX)<br/> 2) some functions in bitmap layer uses blk_t. Sometimes blk_t and blk64_t are used in same operation.<br/> Indeed for large EXT4 file systems extents are used for addressing blocks so bitmap code is not used (LU-XXXX)<br/> 3) Hurd translators<br/> 4) For back compatibility<br/> (LU-XXXX)</p> <p>11. e2fsprogs update<br/> It looks like all 64-bit related patches are landed to master from (<a href="http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/log/" class="external-link" target="_blank" rel="nofollow noopener">http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/log/</a> ) </p> <p> 12. fsck time<br/> fsck for full 256GB partition without errors should require reasonable time. Need to be checked.</p> <p>13. lfsck<br/> lfsck doesn’t use global blocks counters. There are also no other limitations. </p> <p>For points there marker will upload patches in near future. </p> <p>Thank you for this detailed analysis. For some reason I don't recall reading it, maybe because it was posted on Christmas and I was on holidays for a couple of weeks and missed it on my return. In any case it looks very thorough. </p> <p>Some issues I think are important in this area to discuss in advance if you plan to keep enhancing ext4 for even larger OSTs:</p> <ul class="alternate" type="square"> <li>badblocks: this is generally unused, which is why the patch was rejected. That said, I don't know if Darrick went back and audited the badblocks code to properly reject block numbers larger than 2^32 or not.</li> <li>if filesystems get any larger, we will need to force the ext4 meta_bg feature on, because the group descriptors will not be able to fit into the first group after it grows beyond 32767 blocks, ~= 2M groups ~= 256 TB. The meta_bg option is much more efficient than without, but suffers from a lack of robustness because there is only a single copy of the last group's description block (unfortunately this feature was implemented and landed in private before such issues could be discussed and resolved).</li> <li>I don't think there is much value to ldiskfs MDTs with more than 4B inodes. It is always possible to use DNE, which will give better performance and workload isolation, allow parallel e2fsck, and I'm any case there are relatively few systems that are even hitting the 4B limit before seeing problems with performance. If you <em>did</em> want to go down this route, then it makes sense to use the dirdata feature to allow optionally storing the high 32 bits of the inode number into direntries, which is what the first dirdata bit was reserved for. This would keep compatibility with existing directories, and this feature could be enabled on existing filesystems without the need to rewrite all directories with a 64-bit inode direntry, or have problems adding a 64-bit inode number to an existing directory with only 32-bit dirents.</li> <li>probably a feature like bigalloc would be interesting for OSTs since it can speed up allocation performance, but the drawback is that this is very inefficient for small files. This might be compensated by having larger inodes (e.g. 4KB) and then using the online data feature to store smaller files inside the inode. Another benefit of bigalloc is to avoid fragmentation of the <tt>O/0/d&#42;</tt> directories</li> <li>e2fsck performance will become an issue at this scale, and it would likely need to be parallelized to be able to complete in a reasonable time. It could reasonably expect multiple disks at this scale, so having larger numbers of IOs in flight would help, as would an event-driven model with aio that generates lists of blocks to check (itable blocks first), submits them to disk, and then processes them as they are read, generating more blocks to read (more itable blocks, indirect/index/xattr/directory blocks, etc), repeat.</li> <li>I'm not sure if the 16TB extent-mapped file size limit will be important for Lustre, since it is always possible (and desirable for many reasons) to stripe a file widely long before this size is hit for a single file. With PFL it is also possible to restripe a file widely at the end to avoid this problem. True, it would be possible to fill the whole Lustre filesystem with a single file, but that has never been a concern in the past and we've had OSTs &gt; 16TB for some time.</li> <li>the three-level htree/2GB+ directory patch for e2fsck is relatively well understood and described in <a href="https://jira.whamcloud.com/browse/LU-1365" title="Implement ldiskfs LARGEDIR support for e2fsprogs" class="issue-link" data-issue-key="LU-1365"><del>LU-1365</del></a> and seems like a good place to start. The htree limit is relatively easy to test with 1KB blocksize and long filenames with hard links (createmany -l). This has been discussed many time with the other ext4 devs and would very likely be accepted with little complaint.</li> <li>the large xattr patch needs to be able to store 64KB xattrs directly into blocks, and is described in <a href="https://jira.whamcloud.com/browse/LU-908" title="multi-block xattr support" class="issue-link" data-issue-key="LU-908"><del>LU-908</del></a> in detail. Kalpak is also very aware of this, as he worked on it in the past. This might also speed up wide striped file access a bit.</li> </ul> <p>If you are planning to do further enhancements to ldiskfs, I'd strongly recommend to discuss them on the linux-ext4 mailing list first, so they have a chance to be improved and hopefully landed instead of being for Lustre only. </p> <p>More on the MDT side, a couple of interesting possibilities exist:</p> <ul class="alternate" type="square"> <li>the inline_data feature may be of interest on the MDT together with Data-on-MDT, or for small directories.</li> <li>shrinking existing very large but mostly empty directories could be done efficiently. The high bits of the htree logical block pointers are reserved for storing the "fullness" of each leaf block. With the 3-level htree patch, there are 4 bits of space there, which is enough to have 1/16 gradients of fullness. The idea is that when adjacent block become less than, say, 1/3 or 1/4 full they could be merged when deleting files. We don't want to merge when just below 1/2 full, since this could cause repeated split/merge cycles, so some hysteresis is needed. this is actually a topic of interest for ext4 right now, because of high latency to ls a large-but-mostly-empty directory.</li> </ul> <p>PS: if you do plan on working on any new features, we should move the discussion to new tickets, if they don't already have one.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/17702/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/17702/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7592" title="Сhange force_over_128tb lustre mount option to force_over_256b for ldiskfs" class="issue-link" data-issue-key="LU-7592"><del>LU-7592</del></a> osd-ldiskfs: increase supported ldiskfs fs size limit<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 5ca1a1e01d456c09d11d8a3409a83e055a7974a1</p> <p>Artem Blagodarenko (artem.blagodarenko@seagate.com) uploaded a new patch: <a href="http://review.whamcloud.com/19788" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19788</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7592" title="Сhange force_over_128tb lustre mount option to force_over_256b for ldiskfs" class="issue-link" data-issue-key="LU-7592"><del>LU-7592</del></a> osd-ldiskfs: remove force_over_128 warning<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 8f912feba1ce961ab9ba060f7d0674c13968f4a0</p> <p><a href="https://review.whamcloud.com/#/c/19788/3" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/19788</a> is abandoned because its change is landed as part of <a href="https://review.whamcloud.com/#/c/24524/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/24524</a></p> <p>The two patches here were landed for 2.9.0.</p> Related LU-8974 LU-8465 Development Rank 1|hzxwk7: Rank (Obsolete) 9223372036854775807