Fwiw, on my on-metal amd64 WAPBL, I unmounted /usr, ran "fsck -f" on it (-f because it was listed as clean, so I needed to force it), and everything ran apparently error-free. I deleted the dir that contained the recursive ./src (and I noted it also contained ./othersrc, ./xsrc, which makes me actually think "cvs(1) bug???" and then did an apparently trouble-free cvs update... very curious.
One thing I did was check the inode# for the /use/src versus the "recursive" entry, and they were different (I've got no basis for really diagnosing the filesystem, but I wondered if there was a sharing (however erroneous) of inodes) I *do* still have a system that has the problem, but I suspect the effects of the problem won't be illustrative. *How* we get there is the issue. On Dec 17, 2015 7:36 PM, "Gary Duzan" <[email protected]> wrote: > In Message <[email protected]>, > Paul Ripke <[email protected]>wrote: > > =>On Thu, Dec 17, 2015 at 08:24:44PM -0500, [email protected] wrote: > =>> => > =>> => bch <[email protected]> writes: > =>> => > =>> =>> I've run into this a few times: > =>> =>> > =>> =>> U > =>> =>> > =>> > external/bsd/libc++/dist/libcxx/test/libcxx/experimental/containers/sequences/src/external/gpl3/binutils/dist/opcodes/aarch64-tbl.h > =>> =>> > =>> =>> where there are sub-trees seem to be recursively re-added (see > =>> =>> .../src/external/gpl3... as part of ./src/external/bsd/...). > =>> => > =>> => I would unmount the fs and run fsck. I have seen some strange > things > =>> => which were due to filesystem damage. > =>> => > =>> => Then, I'd remove the subtree and update again. > =>> > =>> I've seen this quite a bit on the Xen DOMU that I use for building > =>> NetBSD. So often that I ended up umount/newfs/mount/checkout my src LV > =>> instead of just updating. Every once in a while I try an update; > =>> sometimes it is fine, but other times not. I also just saw it in a > =>> pkgsrc tree I updated on another box recently. After an rm -rf on the > =>> broken tree a subsequent update succeeded, but I expect it could happen > =>> again. In case it matters, I'm using an rsync repo clone and accessing > =>> it over ssh. > =>> > =>> Gary Duzan > => > =>I've seen filesystem corruption, which I now believe to be caused by > =>"rsync --del" access patterns, a number of times over the last year. > =>For now, I've switched to "rsync --delete-delay", and yet to see a > =>re-occurence. > => > =>Ref, long thread over the last year: > =>https://mail-index.netbsd.org/tech-kern/2014/08/29/msg017597.html > > My repo filesystem seems ok. > > # fsck -f /usr/netbsd-cvs > ** /dev/rxbd3d > ** File system is already clean > ** Last Mounted on /usr/netbsd-cvs > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 660135 files, 10936349 used, 9707225 free (49689 frags, 1207192 blocks, > 0.2% fragmentation) > > I ran a level 0 dump on it, and it did not complain. FWIW, the > filesystem is WAPBL, the DOM0 is NetBSD 6.1_STABLE amd64, xbd3 is > an LV in vg0, and vg0 has a single PV on a RAID1 raidframe. Simple. > :-) The DOMU is 7.0_RC3 amd64. > > I'll try tar on the mounted filesystem in case it is a kernel > filesystem issue. It feels more like a client issue, though. My > src filesystem is even more layered: > > ffs+wapbl>lv>vg>2*pv>dk>gpt>xbd>DOM0-lv>vg1>pv>dk>gpt>raid0>2*raid1>2*dk>gpt. > > Gary Duzan > > >
