Re: kern/50707: rm: fts_read: No such file or directory

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jan 25, 11:19pm, joel.bertrand%systella.fr@localhost (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) wrote:
-- Subject: Re: kern/50707: rm: fts_read: No such file or directory

| Christos Zoulas a écrit :
| > The following reply was made to PR kern/50707; it has been noted by GNATS.
| >
| > From: christos%zoulas.com@localhost (Christos Zoulas)
| > To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
| > 	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
| > Cc:
| > Subject: Re: kern/50707: rm: fts_read: No such file or directory
| > Date: Mon, 25 Jan 2016 17:02:15 -0500
| >
| >   On Jan 25, 10:00pm, joel.bertrand%systella.fr@localhost (joel.bertrand%systella.fr@localhost) wrote:
| >   -- Subject: kern/50707: rm: fts_read: No such file or directory
| >
| >   Are you using log (WAPBL) with this filesystem?
| 
| 	I have tried with or without WAPBL with the same result. As I've never 
| seen this issue on sparc64 (FC-AL disks with raidframe), I have 
| suspected in a first time ataraid. Thus I have moved my ataraid 
| configuration to a new raidframe configuration (raid1) and I've seen 
| this issue again.
| 
| 	Thus with or without log, on ataraid or raidframe, system can corrupt a 
| ffsv2 slice. I haven't tested with other filesystems like lfs or without 
| raid.

I am running with raidframe. Perhaps the problem is hardware. I would check
the memory... The disks being at fault is less likely with raidframe.

christos