On Fri, Mar 16, 2018 at 10:06 AM, Eddie Horng <eddiehorng.tw@xxxxxxxxx> wrote: > 2018-03-16 15:23 GMT+08:00 Amir Goldstein <amir73il@xxxxxxxxx>: [...] >>> Hi Amir, >>> The patch works like a charm in my first test, but when I switch lower >>> layer to different fs then upper and merged, problem comes again. The >> >> Yes, that is expected. As I explained, overlayfs does NOT guaranty consistency >> of d_ino to st_ino with non-samefs and this patch doesn't change that. >> Apparently, the consequence is that with NFSv3 you will get DT_UNKNOWN. >> >> If this is really a problem for your use case, I have already posted a solution >> for non-samefs while back https://github.com/amir73il/linux/commits/ovl-xino >> I can rebase and re-post if you are interested in testing. >> Can I assume from your test example that you are interested in the setup of >> ext4 as upper/lower (but non samefs)? Because solving the problem for ext4 >> (32bit ino) is a bit simpler than the general case (64bit ino). >> >> Thanks, >> Amir. > > My setup for upper is ext4, lower however is a proprietary fs, whose > ino is 32bit. > So far it has identical behavior as ext4 to work with overlay. I'm > glad to test if the solution works > for ext4 or the proprietary fs. > In the other hand, I also try to submit a request to Google to see if > the build tool can handle > DT_UNKNOWN properly, after all the application use d_type should do that. > Eddie, I rebased and push branch ovl-xino [1] to my github, it includes the fix you already tested. If your proprietary filesystem does not implement the operation encode_fh() and uses the default 32INO encoding then you don't have to specify any new mount option. If it implements its own file handle encoding, you need to specify overlay mount option -o xino to declare that all inode numbers are limited to 32bit (or at least not using 64bit). Cheers, Amir. [1] https://github.com/amir73il/linux/commits/ovl-xino -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
