Re: Fwd: Re: A new look at old NFS readdir() problems?
От | Peter Eisentraut |
---|---|
Тема | Re: Fwd: Re: A new look at old NFS readdir() problems? |
Дата | |
Msg-id | dce20c98-035e-45a5-b418-1d333e9568e9@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Fwd: Re: A new look at old NFS readdir() problems? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fwd: Re: A new look at old NFS readdir() problems?
|
Список | pgsql-hackers |
On 03.01.25 02:58, Tom Lane wrote: > I wrote: >> Thomas Munro <thomas.munro@gmail.com> writes: >>> For what little it's worth, I'm not quite convinced yet that FreeBSD's >>> client isn't more broken than it needs to be. > >> I'm suspicious of that too. > > 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? It seems like we're probably not the first to have this use case, so there should be some information or problem reports about this somewhere out there. Or if not, then I'd be tempted to think, someone broke it recently, even if the NFS hacker argues that it cannot possibly work and never should have worked.
В списке pgsql-hackers по дате отправления: