On 2019/3/28 下午10:07, David Sterba wrote:
> On Thu, Mar 28, 2019 at 10:00:22PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/3/28 下午9:57, David Sterba wrote:
>>> On Thu, Mar 28, 2019 at 09:42:59PM +0800, Qu Wenruo wrote:
>>>>
>>>>
>>>> On 2019/3/28 下午9:38, David Sterba wrote:
>>>>> On Wed, Mar 20, 2019 at 02:37:16PM +0800, Qu Wenruo wrote:
>>>>>> + if (S_ISDIR(mode) && btrfs_inode_nlink(leaf, iitem) > 1) {
>>>>>> + inode_item_err(fs_info, leaf, slot,
>>>>>> + "invalid nlink: has %u expect no more than 1 for dir",
>>>>>> + btrfs_inode_nlink(leaf, iitem));
>>>>>> + goto error;
>>>>>> + }
>>>>>
>>>>> I'm not sure about this check, the number of links for a directory is 1,
>>>>> but the exact count could be implemented (there's a project idea for
>>>>> that). I don't know if this will require an incompat bit or not.
>>>>
>>>> That means we have hard link for directories.
>>>
>>> Yes, hard links of directories are forbidden by VFS but that's not the
>>> point here:
>>>
>>> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Track_link_count_for_directories
>>>
>>> "The link count for directories is traditionally used to count the number
>>> of subdirectores iff the link count is >= 2."
>>
>> Oh, got it.
>>
>> But for that case, it would be much better to go for things like nbytes
>> or size, as by all means, those two members are less meaningful than
>> nlinks for directory.
>
> size of a directory is currently 2 * sum of all names in the directory,
> ie. both files and directories.
In fact that's not always the case for older kernels/progs.
IIRC it's in recent years that we enhanced btrfs-progs to detect and fix
that.
> The nlink is used as an optimization
> during traversal by existing tools (find), we can't simply change that
> but would still like to update btrfs to provide support for that.
But current nlinks is persistent against all inodes. It's always the the
number of INODE_REF the inode has.
While for size/nbytes, it doesn't make anything for directory inode at all.
Kernel doesn't care, it's mostly btrfs-check check and fix.
Furthermore, only size is fixed to 2 * num_children.
nbytes is only instructive and at least in lowmem mode, nbytes is only
checked for alignment, even it's unaligned, lowmem check outputs warning
only, doesn't count as an error.
So at least to me, directory nbytes is a better alternative, and it's
back compatible.
Thanks,
Qu
>
> On the wiki there's note that it's backward compatible, I don't recall
> the actual details why it's safe though.
>
