目录缓存

1、目录用于存储从服务器获取的目录列表信息。目录无法保证是一直有效的。
2、如何让目录失效，现在采取的是定时。这中方法跟上下文没有关系。如：根据使用次数，最短访问等。
   使它失效不是因为没有了空间。而是因为他可能在其他地方改变了。说实话这种保障机制也很被动。
3、目录失效和对目录的访问如何协作。在open getattr rename release mkdir rmdir unlink create
   这些地方都需要对目录的访问。在大多数情况下我们访问的是本地的缓存。访问本地缓存，和删除本地
   缓存之间需要同步。正在访问的过程中可能被删除。
4、设置dir 访问的链接数。我们确定它过期了就把它删除。这里还可以这样，如果我们访问了一次dir 比较
一下它的时间，确定他过期了，那么就把它删除掉，链接数用来确定没有其他人访问。如何与定时删除机制结合起来。定时删除用来清除很久没有被访问的对象。
5、map 自身需要同步管理。dir 也需要。
6、也可以在需要访问一个对象时，我们获取到它时，看看它是否已经过期了。过期了，我们就去服务器要。
结合定时清除。定时清除的时间是很长的。我们清理的对象也是很久没有使用的对象。过期时间是两秒的话，
我们清理的时间是1分钟。如果一个对象已经过时了30秒。那么就把它清除。这里只是保证不被访问的对象不要占据空间。
7、6方案依然无法解决对象之间同步问题。删除，访问。这种交互的情况还是存在。另外，访问之间也存在交互。如对象的插入，删除。在dir 内部需要设置? 这里可能要注意一点。系统顶层对于这些是否做了优化。我们这么做并不需要很多的消耗，这里主要指时间。从这个角度来看，我们应该设计这样的同步机制。

8、如果dir 每次的使用都是包含在锁中间的。那么内部也就只能是顺序执行。性能影响:我们锁住的是dir对象。而且这些访问时间是很少的。

9、dir 的出口和入口都很多。dir使用的序列。

10、删除dir根据的都是时间。定期轮询删除，访问确定过期删除+轮询删除都可以解决这个问题。
    但是都没有办法保证dir使用时的安全。
    可以看做这样。 read write delete 这些序列之间要保持。
    从map 中找到dir。这个部分应该是有map 锁的。从map中删除也是有锁保护的。
    接着使用dir。这个时候map 锁已经去掉了。dir不受保护。
    我们保护的只是dir 放入map 或者是从map中取出这个部分。
   
    从map中删除和查找这本身应该是一个原子操作。
    我们现在把整体作为一个原子。所以不好在其中再加锁。
    如果我们对于找到的每一个对象进行加锁
    这样去掉了原子操作。map 的游标移动的过程中，可能被其他操作修改了什么。

    我们保证map删除对象是事务操作。同时保证dir删除时，没有人使用了。
  
   如果它在被多人使用，我们需要保证它被使用完了。
    允许它被多人使用吗？？
   处理这样的事情。允许哪里的通道是宽松的。那里是单一的顺序的通过。

11、从什么地方开始记入同步范围。我们访问一个目录。开始还没有形成dir对象。

12、可以想想数据的来源。在哪里进行控制。dir单一访问的控制可以考虑放在rest部分。

13、如何看待对于环境的假设。这点比较重要。合理的利用环境可以把事情更高效。有了环境有了背景，
   许多事情就可以确定发生的可能性。但不能假设环境。是需要通过验证的。

14、我们把dir的具体删除放置到另外一个线程中去，我们只是把它从map中脱离了。这个时候
    我们不想在删除map对象的过程中去等待删除它。实际上也可以。我们保证了map修改的原子性。
    确认存在和进行操作应该是原子的。
    这里相当于我们建立了一个线程来回收这些资源。
    使用一个线程清除，可能需要等待。但是只要把dir 对象从map中清除掉。就没有人回再去访问它了。
    已经在入口处把它关闭了。这样我们可以慢慢考虑它的清除工作了。

15、dir 中的file对象是否可以用来做访问对象。我们如果可以全面控制dir 的删除。那么我们也可以在删除dir时，去判断一下这个对象的使用情况。如果它是正在使用的。那么就留着它。它自己会清除的。这个需要进一步的分析。现在的方案较为稳定。不用更换。

16、把dir相关的操作给提取出来。在很多地方有相似的代码。

17、real_getdir 是先在本地查找dir，如果没有从网络下载。从网络下载后，会添加到本地缓存。如果同时刻多次访问，后面的也会在本地缓存中找到。这样dir的获取在map中都是受到保护的。找到后，我们依照我们的需求开始进行处理。这部分处理是没有进行保护的。

18、我不是对dir进行访问，而是访问其中的file对象，也是需要保护的。因为没有对file删除设置保护。
    是否建立起file对象本身的保护

19 从map 取出来。然后使用dir。这是两个分开的操作。其中可能穿插map删除dir这种情况。用sleep检查。会出现交互的糟糕情况。要让删除的人知道现在又人在使用。在锁中间进行++操作没有意义。
进入锁中间就不需要害怕了。
锁的外面可能把对象给解决掉了。如何判断这个对象是否已经解决了。
在锁内进行二次搜索。查看它是不是NULL。我们既然进入了，应该来说是一定会在本地的。
另外如果删除，锁也无法使用。
20 这样问题存在的地方就在于对象会删除。这种情况其他人是如何处置的。采用信号量是否会解决问题。
我们使用时++，
  1、采用更大范围的锁可以解决。
  2、采用
  3、允许这种情况存在。它的可能性是存在的

20、release 时不需要对文件进行更新。如果本地没有那么就不要去服务器查找了。留给下一个操作。

21、对于锁的情况，除了死锁的情况不要使用以外，其他的可以放松使用。

22、使用锁保证访问是依次进行，出现了问题.一个目录下有很多对象。这些对象只能一个个来寻找属性。
这样花费了很多时间；另外，在查找的过程中，一个对象在查找的过程中。目录对象被其他人给删除掉了。
这样引起内存错误。
   1、必须保证使用正确性。删除对象必须知道
   2、慢速的问题是另外的程序引起的。

23、使用了多线程，让许多问题变得不再单一。但是问题本身更接近实际。多线程下面，与锁相同生命周期的对象在删除时，它自身对象依然没有得到处理。是否需要其他对象来做辅助。