Re: SCSi issues after 10.0 update
David Brownlee <[email protected]> Mon, 10 Jun 2024 22:00:45 +0100
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <CAGN_6pZ+fZog7FFNOi9fZeN18UY-p641VDgq_sSjeDhxim+xdA@mail.gmail.com> |
On Mon, 10 Jun 2024 at 16:22, Riccardo Mottola <[email protected]> wrote: > > Hi, > > David Brownlee wrote: > > If you saw the initial issues with over NFS then bonnie++ over NFS > > could be an excellent test > > > > (Many moons ago I used bonnie running on a handful of render clients > > to show a proposed migration to Origin 2000 servers with Fore Systems > > ATM drivers was going to be a disaster - repeatably triggering a panic > > within a minute or so) > > I did connect a FreeBSD workstation running amd64 over wired ethernet to > NFS serverd (same nfs that was in use when the issue happened). SO to > use a reliable workstation and not other sparc clients, no doubts over > doubts :) > Stopped other clients... just not interrupt work. Serial console on the > Netra T1 to see errors, logs, hangs. > > Run bonnie++ on the FreeBSD workstation on NFS mounted volume, with > small size (128MB)- Starts to run but fails when removing directories: > > start 'em...done...done...done...done...done... > Create files in sequential order...done. > Stat files in sequential order...done. > Delete files in sequential order...Bonnie: drastic I/O error (rmdir): > Directory not empty > Cleaning up test directory after error. > > Actually, nothing was cleaned up.. I found the directory full of tmp > files. Tried to delete it manually and it worked fine.... > > Run bonnie++ on internal hard disks of the Netra, both disks work. > > I tried running boniee++ locally + remotely (even if it fails)... this > should have tortured things a little bit, but no failure! No warnings in > dmesg! > > Maybe it was really a bad day.. and a difficult to reproduce bug... > however the fact that bonnie++ is not reliable over NFS isn't nice either. That is unfortunate :/ When the issue triggered before which clients were busy - was it the sparcs? I'm wondering if it may also be related to the specific use patterns of those clients - also might be interesting to know if they fail on rmdir the same way... David