On 2012-08-14, at 9:19, Theodore Ts'o <tytso@xxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
