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-14510 Lustre <p>Creating a DoM PFL file and then running "<tt>filefrag -v</tt>" on it (<tt>ioctl(FIEMAP)</tt>) does not work:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># lfs setstripe -E 1M -L mdt -E 16m -c 4 -E eof -c -1 /mnt/testfs/dom-pfl # dd if=/dev/zero of=/mnt/testfs/dom-pfl2 bs=1M count=1 # filefrag -v /mnt/testfs/dom-pfl2 Filesystem type is: bd00bd0 File size of /mnt/testfs/dom-pfl2 is 1048576 (1024 blocks of 1024 bytes) /mnt/testfs/dom-pfl2: FIBMAP unsupported </pre> </div></div> <p>The "<tt>FIBMAP unsupported</tt>" message is a bit misleading, since it tries <tt>FIEMAP</tt> first, but falls back to <tt>FIBMAP</tt> if that doesn't work.</p> LU-14510

FIEMAP does not work on DoM files

Bug Minor Open Unresolved WC Triage Andreas Dilger DoM2 e2fsprogs Wed, 10 Mar 2021 22:05:22 +0000 Wed, 10 Mar 2021 23:06:52 +0000 Lustre 2.14.0 Lustre 2.12.6 Lustre 2.15.0 0 1 <p>One issue that we need to decide is what the "device number" should be for MDT components of a file? Currently, we use device "0..nnnn" to represent OST0000..OSTxxxx, so we would have to use some other numbering for the MDT. While this is a 32-bit number and we only allow up to 65536 OSTs, unfortunately the high 16 bits were already consumed by storing the component number for <a href="https://jira.whamcloud.com/browse/LU-11848" title="filefrag/FIEMAP doesn&#39;t work for PFL or FLR files" class="issue-link" data-issue-key="LU-11848"><del>LU-11848</del></a> to handle PFL files.</p> <p>Another option would be to use an extent flag like <tt>FIEMAP_EXTENT_DATA_INLINE</tt> to indicate the data is being stored on the MDS. Strictly speaking, the <tt>FIEMAP_EXTENT_DATA_INLINE</tt> flag indicates that the data is stored <em>inside</em> the inode, and at some point we may want to allow this with the <tt>inline_data</tt> feature, but it might be a convenient short-term hack. A better solution would be to have a new flag like <tt>FIEMAP_EXTENT_METADATA=0x40000000</tt>, but it has some chance of conflict with other flags in the future unless we can add some upstream functionality that also uses this flag.</p> Related LU-11848 Development Rank 1|i01p1r: Rank (Obsolete) 9223372036854775807 Severity