# Re: \[PATCH V5 00/23\] ext4: Add inline data support.

- From: Andreas Dilger \<hidden\>
- Date: 2012-08-15 02:51:41 
- List: linux-ext4
- Page: https://ratatoskr.run/linux-ext4/2012/08/13415884
- Thread: https://ratatoskr.run/linux-ext4/2012/06/13415421/t.md

```text
On 2012-08-14, at 9:19, Theodore Ts'o [ref] wrote:

> On Tue, Aug 14, 2012 at 03:04:47PM +0800, Tao Ma wrote:
>> As andreas said in another e-mail, that would make the codes a little
>> complex. So in general, in my previous version, I just tried to refactor
>> most of the codes so that they can work for both inline inode and dir
>> blocks. But if these changes are merged, we have to re-write all of the
>> codes that are currently shared, such as ext4_find_entry, empty_dir,
>> ext4_add_entry etc.
> 
> Well, we may not need to rewrite as much as you think.  For one thing,
> as I mentioned, I don't think the VFS passes '.' and '..' lookup
> requests down to the file system anyway, and even if it did, you could
> just have a function which checks for '.' and '..' and returns the
> correct value if necessary.

Actually, NFS can submit lookups for ".." for path linkage IIRC, since we had to implement a patch to fix this for ext4 and Lustre at one time.

> So I think you wouldn't need to rewrite
> all of these functions, since the fundamental layout of the directory
> wouldn't be changing.  It's just that we're skipping the '.' and '..'
> entries, and the "standard" directory layout would be starting 4 bytes
> later (after the '..' inode number).

Agreed, the "." and ".." lookups are already special cases in the lookup code.

Cheers, Andreas

> So it's probably worth taking a look to see how much of an increase in
> complexity would actually be involved.
> 
> Regards,
> 
>                    - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
```