git.notmuchmail.org Git - notmuch/blob - test/corpora/lkml/cur/1382298770.002911:2,

   1 From: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
   2 Subject: Re: [RFC][PATCH 05/10] cifs: define superblock-level cache index
   3  objects and register them
   4 Date: Fri, 25 Jun 2010 18:14:16 +0530
   5 Lines: 41
   6 Message-ID: <4C24A4A0.90408@suse.de>
   7 References: <1277220206-3559-1-git-send-email-sjayaraman@suse.de> <yes> <9720.1277312290@redhat.com>
   8 Mime-Version: 1.0
   9 Content-Type: text/plain; charset=UTF-8
  10 Content-Transfer-Encoding: 7bit
  11 Cc: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
  12         linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  13 To: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  14 X-From: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Fri Jun 25 14:44:28 2010
  15 Return-path: <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
  16 Envelope-to: glkc-linux-cifs-1dZseelyfdZg9hUCZPvPmw@public.gmane.org
  17 Received: from vger.kernel.org ([209.132.180.67])
  18         by lo.gmane.org with esmtp (Exim 4.69)
  19         (envelope-from <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>)
  20         id 1OS8Gh-0005Bb-E2
  21         for glkc-linux-cifs-1dZseelyfdZg9hUCZPvPmw@public.gmane.org; Fri, 25 Jun 2010 14:44:27 +0200
  22 Received: (majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org) by vger.kernel.org via listexpand
  23         id S1754703Ab0FYMo0 (ORCPT <rfc822;glkc-linux-cifs@m.gmane.org>);
  24         Fri, 25 Jun 2010 08:44:26 -0400
  25 Received: from cantor.suse.de ([195.135.220.2]:51036 "EHLO mx1.suse.de"
  26         rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
  27         id S1754222Ab0FYMoZ (ORCPT <rfc822;linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>);
  28         Fri, 25 Jun 2010 08:44:25 -0400
  29 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2])
  30         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
  31         (No client certificate requested)
  32         by mx1.suse.de (Postfix) with ESMTP id E07FF8FEA2;
  33         Fri, 25 Jun 2010 14:44:24 +0200 (CEST)
  34 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0
  35 In-Reply-To: <9720.1277312290-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
  36 Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  37 Precedence: bulk
  38 List-ID: <linux-cifs.vger.kernel.org>
  39 X-Mailing-List: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  40 Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1002945>
  41
  42 On 06/23/2010 10:28 PM, David Howells wrote:
  43 > Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
  44 >
  45 >> Define superblock-level cache index objects (managed by cifsTconInfo
  46 >> structs).  Each superblock object is created in a server-level index object
  47 >> and in itself an index into which inode-level objects are inserted.
  48 >>
  49 >> Currently, the superblock objects are keyed by sharename.
  50 >
  51 > Seems reasonable.  Is there any way you can check that the share you are
  52 > looking at on a server is the same as the last time you looked?  Can you
  53
  54 Good point.
  55
  56 I thought of using TID (Tree identifier; a unique ID for a resource in
  57 use by client) along with sharename. But, Server is free to reuse them
  58 when the tree connection closes and does not guarantee the same Tid for
  59 a particular resource across tree connections.
  60
  61 Also, considering the UNC name of the resource (//server/share) may not
  62 be a good idea too as the cache will not be used when for e.g. IPaddress
  63 is used to mount.
  64
  65 So, if a server does something like this:
  66    - export a share 'foo' (original server path: /export/vol1/foo)
  67    - client mounts and uses it
  68    - server unexports the share 'foo'
  69    - server exports 'foo' (original sever path: /export/vol2/foo)
  70
  71 we have a bit of problem..
  72
  73 > validate the root directory of the share in some way?
  74 >
  75
  76 I don't know if there is a way to do this.
  77
  78 Thanks,
  79
  80
  81 --
  82 Suresh Jayaraman
  83
  84