linux – rename()原子性和NFS?
参考:
Is rename() atomic?
我问的是类似的东西,但不完全相同,因为我想知道的是在使用NFS时依赖于rename()的原子性是否安全? 这是我正在处理的一个场景 – 我有一个必须始终存在的’索引’文件. 所以: >客户端创建一个新文件 独立客户: >读取索引文件 这假设rename()是原子意味着 – 总会有一个’索引’文件(尽管它可能是一个过时的版本,因为缓存和时间) 但是我遇到的问题是 – 这发生在NFS上 – 并且正在工作 – 但我的几个NFS客户端偶尔会报告“ENOENT” – 没有这样的文件或目录. (例如,在每隔5米发生的数百次操作中,我们每隔几天就会收到此错误). 所以我希望是否有人能够启发我 – 在这种情况下,实际上是否真的不可能获得’ENOENT’? 我问的原因是RFC 3530这个条目:
我想知道这是否只是发出重命名的客户端,而不是查看目录的客户端? (我对缓存/过时的目录结构没问题,但是这个操作的重点是这个文件总是以某种形式“存在”) 操作顺序(来自执行写操作的客户端)是: 21401 14:58:11 open("fleeg.ext",O_RDWR|O_CREAT|O_EXCL,0666) = -1 EEXIST (File exists) <0.000443> 21401 14:58:11 open("fleeg.ext",O_RDWR) = 3 <0.000547> 21401 14:58:11 fstat(3,{st_mode=S_IFREG|0600,st_size=572,...}) = 0 <0.000012> 21401 14:58:11 fadvise64(3,572,POSIX_FADV_RANDOM) = 0 <0.000008> 21401 14:58:11 fcntl(3,F_SETLKW,{type=F_WRLCK,whence=SEEK_SET,start=1,len=1}) = 0 <0.001994> 21401 14:58:11 open("fleeg.ext.i",O_RDWR|O_CREAT,0666) = 4 <0.000538> 21401 14:58:11 fstat(4,st_size=42,...}) = 0 <0.000008> 21401 14:58:11 fadvise64(4,42,POSIX_FADV_RANDOM) = 0 <0.000006> 21401 14:58:11 close(4) = 0 <0.000011> 21401 14:58:11 fstat(3,...}) = 0 <0.000007> 21401 14:58:11 open("fleeg.ext.i",O_RDONLY) = 4 <0.000577> 21401 14:58:11 fstat(4,...}) = 0 <0.000007> 21401 14:58:11 fadvise64(4,POSIX_FADV_RANDOM) = 0 <0.000006> 21401 14:58:11 fstat(4,...}) = 0 <0.000007> 21401 14:58:11 fstat(4,...}) = 0 <0.000007> 21401 14:58:11 read(4,"3PAX1 O}270370206202252422t2 203RD 17r 2 n"...,42) = 42 <0.000552> 21401 14:58:11 close(4) = 0 <0.000013> 21401 14:58:11 fcntl(3,{type=F_RDLCK,start=466,len=68}) = 0 <0.001418> 21401 14:58:11 pread(3,"21@203244I240333272252d3162613770361#222200313224&J2535354217-256LA345253"...,38,534) = 38 <0.000010> 21401 14:58:11 pread(3,"21"30361241223271256317302363262F276]260241-x227b3772053562522362113717.216364"...,68,466) = 68 <0.000010> 21401 14:58:11 pread(3,"21302d344327O207C]M10xxM3772340 319206k201N372332265R242313S24H"...,62,300) = 62 <0.000011> 21401 14:58:11 pread(3,"21362cv'37204]377q362N302/2122552553702002363502237>7i`346271Cy370"...,104,362) = 104 <0.000010> 21401 14:58:11 pwrite(3,"213023174252273.17v247313324267C222P303n~341F24oh/300a315n32131256"...,127,572) = 127 <0.000012> 21401 14:58:11 pwrite(3,"21212Q325371223235256245247WT$4227375[3263222 305 342049A;2U"...,699) = 68 <0.000009> 21401 14:58:11 pwrite(3,"2126220Kc(!.350367i253hkl~254335H250.d 036r342v242725521431"...,767) = 38 <0.000009> 21401 14:58:11 fsync(3) = 0 <0.001007> 21401 14:58:11 fstat(3,st_size=805,...}) = 0 <0.000009> 21401 14:58:11 open("fleeg.ext.i.tmp",O_RDWR|O_CREAT|O_TRUNC,0666) = 4 <0.001813> 21401 14:58:11 fstat(4,st_size=0,POSIX_FADV_RANDOM) = 0 <0.000007> 21401 14:58:11 write(4,"3PAX1 qT2225226202252422t2 205;D 17r 2 n"...,42) = 42 <0.000012> 21401 14:58:11 stat("fleeg.ext.i",...}) = 0 <0.000011> 21401 14:58:11 fchmod(4,0100600) = 0 <0.002517> 21401 14:58:11 fstat(4,...}) = 0 <0.000008> 21401 14:58:11 close(4) = 0 <0.000011> 21401 14:58:11 rename("fleeg.ext.i.tmp","fleeg.pax.i") = 0 <0.001201> 21401 14:58:11 close(3) = 0 <0.000795> 21401 14:58:11 munmap(0x7f1475cce000,4198400) = 0 <0.000177> 21401 14:58:11 munmap(0x7f14760cf000,4198400) = 0 <0.000173> 21401 14:58:11 futex(0x7f147cbcb908,FUTEX_WAKE_PRIVATE,2147483647) = 0 <0.000010> 21401 14:58:11 exit_group(0) = ? 21401 14:58:11 +++ exited with 0 +++ 注意 – 上面重命名的路径和文件是为了保持一致性. fleeg.ext是数据文件,fleeg.ext.i是索引.在此过程中 – fleeg.ext.i文件被覆盖(由.tmp文件),这就是为什么相信该路径上应该始终存在一个文件(旧文件或刚被覆盖的新文件)它). 在阅读客户端上,PCAP看起来像LOOKUP NFS调用是失败的: 124 1.375777 10.10.41.35 -> 10.10.41.9 NFS 226 LOOKUP fleeg.ext.i V3 LOOKUP Call,DH: 0x6fbbff3a/fleeg.ext.i 125 1.375951 10.10.41.9 -> 10.10.41.35 NFS 186 5347 LOOKUP 0775 Directory V3 LOOKUP Reply (Call In 124) Error: NFS3ERR_NOENT 126 1.375975 10.10.41.35 -> 10.10.41.9 NFS 226 LOOKUP fleeg.ext.i V3 LOOKUP Call,DH: 0x6fbbff3a/fleeg.ext.i 127 1.376142 10.10.41.9 -> 10.10.41.35 NFS 186 5347 LOOKUP 0775 Directory V3 LOOKUP Reply (Call In 126) Error: NFS3ERR_NOENT 解决方法
我认为问题不在于RENAME不是原子的,而是因为通过NFS打开文件不是原子的.
NFS使用Filehandles;为了对文件做某事,客户端首先通过LOOKUP获取Filehandle,然后使用获得的Filehandle来执行其他请求.至少需要两个数据报,并且在特定情况下,它们之间的时间可能非常“大”. 我想,你发生的事情是客户端(client1)执行LOOKUP;之后,LOOKUP文件被RENAME(by client2)删除; Filehandle client1不再有效,因为它引用的是inode,而不是指向命名的路径. 所有这一切的原因是NFS旨在成为无国籍人.更多信息在此PDF:http://pages.cs.wisc.edu/~remzi/OSTEP/dist-nfs.pdf 在第6和第8页中,这种行为得到了很好的解释. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |