Re: Fwd: Re: A new look at old NFS readdir() problems?
От | Tom Lane |
---|---|
Тема | Re: Fwd: Re: A new look at old NFS readdir() problems? |
Дата | |
Msg-id | 469548.1735927963@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fwd: Re: A new look at old NFS readdir() problems? (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Fwd: Re: A new look at old NFS readdir() problems?
|
Список | pgsql-hackers |
Peter Eisentraut <peter@eisentraut.org> writes: > On 03.01.25 02:58, Tom Lane wrote: >> I poked at this a little further. I made the attached stand-alone >> test case (you don't need any more than "cc -o rmtree rmtree.c" >> to build it, then point the script at some NFS-mounted directory). >> This fails with my NAS at least as far back as FreeBSD 11.0. >> I also tried it on NetBSD 9.2 which seems fine. > If you use some GUI file manager, point at a directory, and select > "remove this directory with everything in it", what does it do > internally? Surely it runs a readdir() loop and unlinks the files as it > gets to them? Or does it indeed slurp the whole directory tree into > memory before starting the deletion? One thing I noticed while testing yesterday is that "rm -rf foo" worked even in cases where "rmtree foo" didn't. I did not look into FreeBSD's rm code, but I'll bet it has the sort of retry logic that was recommended to us upthread. I agree with your point though that it's hard to believe that everyone does that in every case where it would matter. As for pre-existing bug reports, I found https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=57696 but there's basically no new information there, other than the not-so-surprising fact that renaming directory entries triggers the failure as efficiently as unlinking does. regards, tom lane
В списке pgsql-hackers по дате отправления: