I have meetings starting soon and lasting for several hours so I cannot be as detailed as I'd like in this reply.
I believe I see the processing that you describe. I had modified the NULL derived layer's *_readdir_cb() function. I enabled full debug logging for all components and started reviewing that information. I'm not yet done reviewing the information but it looks like mdcache_refresh_atttributes() processing is setting the file size to the unadjusted size. If you desire, I can provide patches so you could see the NULL derived layer. If you have access to very large transfer locations, I could even provide VirtualBox virtual PCs with my test configuration. On 12/21/2016 08:13 AM, Daniel Gryniewicz wrote: > Hi, Kevin. > > Welcome! Glad someone's getting use out of stacking. > > First, your stack. It sounds like you're stacking like this: > > MDCACHE > | > NULL (modified) > | > PROXY > > Correct? > > The readdir() path is somewhat different than the lookup/open path. In > a normal lookup (say), the call comes into the protocol layer, and is > passed to MDCACHE, and so down the stack, to the bottom FSAL, which > creates a handle. The handle is then passed back up the stack, each > layer wrapping it as it goes, until MDCACHE creates it's handle and > caches it. Future attempts to get the metadata (getattr() calls) are > handled directly by MDCACHE until the cache entry times out, or until an > event causes cache invalidation on the entry. > > For readdir(), however, no lookup is ever made. The Protocol layer > calls readdir(), which calls into MDCACHE. MDCACHE then caches the > *entire* directory worth of dirents for the directory (except for large > directories, but we'll skip that for a second). This involves calling > readdir() down the stack starting at 0 and going until there are no more > entries. > > However, a readdir() call doesn't just create directory entries, it also > materializes handles for each object in the directory, and passes them > back up. This includes attributes, which are cached at the MDCACHE > layer as stated before. > > This means that any modification of size or other attributes that you do > on create(), lookup(), or getattr() must also be done during readdir(), > or the full original attributes will be cached, causing the incorrect > values to be returned until the entry times out. > > Does this help? > > Daniel > > On 12/20/2016 02:49 PM, Kevin C. wrote: >> I'm trying to simplify migration away from a legacy non-standard NFS >> server by creating a stackable FSAL. For my tests, I’m using a slightly >> modified copy of FSAL NULL above FSAL PROXY. >> >> Reads from the legacy non-standard NFS server includes data not >> originally provided by user application writes. Writes to the legacy >> non-standard NFS server also requires insertion of data not provided by >> the user application. I am unable to change the legacy system (anytime >> soon). >> >> For all tests I’ve run, my FSAL NULL derived layer is successfully >> inserting test data. >> >> When file system operations are done in a certain order (e.g. reading >> files before listing directory contents), my FSAL NULL derived layer >> successfully removes the inserted test data from the read data stream >> presented to user applications and FSAL adjusted file sizes are shown by >> file manager GUI or "ls". >> >> If the PROXY NFS server directory contents are listed first (via "ls" or >> file manager GUI) or output via "cat //mnt/nfstst//*", it seems like the >> FSAL NULL derived layer is bypassed. The user applications receive the >> extra/unwanted data as well as the expected user application data and >> directory listings show file sizes that are NOT adjusted to subtract the >> extra/unwanted data portions from the size. >> >> I hope that someone more familiar with NFS-Ganesha's architecture can >> help identify the processing path(s) that I have failed to identify >> (i.e. adjust via the stackableFSAL) so that I can eliminate this >> operation order dependency. >> >> My original work was done on the 2.4 stable branch. The development >> process indicates all patches should be made to the current development >> branch. I've recreated these results with the 2.5 development branch. If >> your input helps me find a bug, I'll submit a fix. >> >> I’m requesting input from more experienced NFS-Ganesha developers. >> Please provide any input that helps me eliminate this processing order >> dependency. >> >> Thanks in advance, >> Kevin >> >> >> >> >> ------------------------------------------------------------------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today.http://sdm.link/intel >> >> >> >> _______________________________________________ >> Nfs-ganesha-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel >> > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today.http://sdm.link/intel > _______________________________________________ > Nfs-ganesha-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ Nfs-ganesha-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
