Update, its on NFS only (Re: ffs corruption on 9.66.69 on qemu)

Hi folks, On Sun, Oct 11, 2020 at 04:10:00PM +0200, Reinoud Zandijk wrote: > qemu-system-x86_64 -m 4096 -accel nvmm -smp cpus=2 -drive \ > file=work/wd0.img,format=raw -nographic -gdb tcp::1234 -net nic -net \ > tap,ifname=tap0,script=no > > Now is this an qemu related problem? I am a bit

Re: FFS corruption

I wrote "that's an inode"; now in living colour: On Mon, Nov 20, 2017 at 08:09:28AM +, Emmanuel Dreyfus wrote: > 80 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 di_mode = 0x8180 = 0100600 (mode 600 regular file) di_nlink = 1 di_oldids = 0 (uninteresting) di_size = 0 > 0010

Re: FFS corruption

On Mon, Nov 20, 2017 at 03:38:32PM -0500, Mouse wrote: > dholland's identification of the overwrite data as inodes certainly > does feel provocative, but I'm not sure what to make of it. Inodes and data blocks should appear in strictly disjoint regions of the fs image. Therefore, either

Re: FFS corruption

>>> After this migration, the filesystem started corrupting the same >>> file /usr/pkg/etc/httpd/httpd.conf at the same time, which happens >>> to be /etc/daily end of execution. >> Which filesystem? The original or the copy? > The copy. It would blow my mind if making a copy of a VM could break

Re: FFS corruption

Mouse wrote: > > After this migration, the filesystem started corrupting the same file > > /usr/pkg/etc/httpd/httpd.conf at the same time, which happens to be > > /etc/daily end of execution. > > Which filesystem? The original or the copy? The copy. It would blow

Re: FFS corruption

> Everything was fine until I scp it over the network on a new machine. > After this migration, the filesystem started corrupting the same file > /usr/pkg/etc/httpd/httpd.conf at the same time, which happens to be > /etc/daily end of execution. Which filesystem? The original or the copy? >

Re: FFS corruption

On Mon, Nov 20, 2017 at 08:09:28AM +, Emmanuel Dreyfus wrote: > 80 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 > || > 0010 5a 8d 0e 5a 60 8e 09 0f 5a 8d 0e 5a 60 8e 09 0f > |Z..Z`...Z..Z`...| > 0020 5a 8d 0e 5a 60 8e 09 0f 00 00 00 00 00 00 00

Re: FFS corruption

On Mon, Nov 20, 2017 at 01:33:44PM +, Christos Zoulas wrote: > I think if the block allocation fails in a bad spot on ffsv2, fsck does > not correct it, so new file allocation from those blocks will fail. But that happened on FFSv1, and on an existig file. -- Emmanuel Dreyfus

Re: FFS corruption

In article <20171120103643.gh4...@trav.math.uni-bonn.de>, Edgar Fuß wrote: >> Is there anything ringing a bell to someone here? >Yes, but I guess that doesn't help. >I experienced something remotely similar after a disc firmware crash followed >by a mpt(4) lockup (before

Re: FFS corruption

> Is there anything ringing a bell to someone here? Yes, but I guess that doesn't help. I experienced something remotely similar after a disc firmware crash followed by a mpt(4) lockup (before I wrote the timeout recovery buhrow@ committed). I would get a "mangled directory" panic on the same

FFS corruption

Hello I experienced some nasty FFS corrupton, which was only resolved by reformatting.L The filesystem was a root partition image for a Xen NetBSD-7.1/i386 domU. It was formatetd FFSv1 level 4. Everything was fine until I scp it over the network on a new machine. After this migration, the

Re: ffs corruption

On Wed, May 24, 2017 at 07:29:44PM +, Emmanuel Dreyfus wrote: > Other VM on the machine have no problems, which suggests it is not a disk > problem. Update: This morning I hit the same problem onanother VM from the same physical machine: $ ls -l /usr/lib/libfetch.so.3

ffs corruption

Hello I experience recurent ffs corruption on a NetBSD-7.1/i386 machine running XEN3PAE_DOMU kernel. The VM has two filesystems and it keeps corrupting them. It will complain about unallocated inodes an bad file descriptors, and a fsck will remove a bunch of files. Other VM on the machine have