On Mon, 13 Feb 2012 12:56:40 +0530 Suresh Jayaraman <sjayaraman@xxxxxxxx> wrote: > On 02/10/2012 11:52 PM, Jeff Layton wrote: > > On Thu, 9 Feb 2012 21:08:12 +0300 > > Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > > > >> Currently we do inc_nlink/drop_nlink for a parent directory for every > >> mkdir and rmdir calls. That's wrong when POSIX extensions are disabled > >> because in this case a server doesn't do the same things and returns > >> the old value on the next QueryInfo request. As the result, we update > >> our value with the server one and then decrement it on every rmdir > >> call - go to negative nlink values. > >> > >> Fix this by doing inc_nlink/drop_nlink for parent directory in mkdir > >> and rmdir in POSIX case only. Also add cERROR when nlink value <= 2 > >> and we still try to decrement it (possible broken servers). > >> > > > > Rather than doing that, I think it would be better not to do the > > inc/dec_nlink in either case and instead to set cifsi->time on the > > parent to 0 for both cases. > > > > That should force it to have the directory attributes refetched at the > > next opportunity. Since we're not doing that now, we're likely missing > > out on stuff like directory mtime changes as well. > > > > Hmm.. don't we have to do both? Keep the nlink value sane and force > refetching attrs. Wondering if we don't update nlink what will happen in > cases > > (a) when mkdir/rmdir is run in a tight loop > (b) when a dir is moved from one to another within the cifs mount > I don't think so -- we either need to fake i_nlink and ignore the value from the server, or treat the server as authoritative. Trying to monkey with the nlink value on the client and overwriting it with the value from the server is always going to be racy. I think the only time it really matters is if you're using generic_drop_inode, which we do when CIFS_MOUNT_SERVER_INUM is set. That said, the values we get out of some servers for i_nlink are non-sensical. Perhaps we'd be best off to just fake the i_nlink value across the board. We have had people in the past complain that i_nlink is always 0 in some cases. -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
