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 hes
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
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 somethin
>>> 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
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 my mind if making a copy of a
> 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?
> http
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 00
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
m...@netbsd.org
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 I wrote the timeout reco
> 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 dir
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 fil
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
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
13 matches
Mail list logo