Re: ffs_newvnode: inode has non zero blocks

> | There are some further changes needed to cover a possible dup alloc , > | and to keep the !wapbl case recoverable by fsck. There is ongoing > | discussion on source-changes about that, hope we finalise fix later in > | the week. > > Leaving a filesystem problem committed on head that can cause

Re: ffs_newvnode: inode has non zero blocks

On Nov 8, 11:51am, jaromir.dole...@gmail.com (=?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?=) wrote: -- Subject: Re: ffs_newvnode: inode has non zero blocks | Yes, that problem is related to the wapbl change. I've committed a bug | fix, so newer kernel shouldn't trigger the panic any more

Re: ffs_newvnode: inode has non zero blocks

Yes, that problem is related to the wapbl change. I've committed a bug fix, so newer kernel shouldn't trigger the panic any more. There are some further changes needed to cover a possible dup alloc , and to keep the !wapbl case recoverable by fsck. There is ongoing discussion on source-changes

Re: ffs_newvnode: inode has non zero blocks

Jaromír Doleček wrote: > There was recenly change a change in FFS in the general area for > WAPBL. Can you try attached patch and check if following KASSERT() > triggers? I'm afraid I took your request literally and tested a release build with your patch and no other changes. Since KASSERT does

Re: ffs_newvnode: inode has non zero blocks

Earlier, I wrote: > Also, I have now narrowed down the appearance of the problem on the > testbed to the following commit: > > 2016.10.30.15.01.46 christos src/sys/ufs/ffs/ffs_alloc.c 1.154 > > The mystery remains because the commit message says there should be no > functional change, and I

Re: ffs_newvnode: inode has non zero blocks

Jaromír, Earlier, I wrote: > I can't do automated installs of sparc under qemu>0 because of > https://bugs.launchpad.net/qemu/+bug/1399943, After some discussion with the qemu maintainers, it looks like bug 1399943 has been fixed, so I should be able to test your patch after all, as soon as the

Re: ffs_newvnode: inode has non zero blocks

Jaromír Doleček wrote: > There was recenly change a change in FFS in the general area for > WAPBL. Can you try attached patch and check if following KASSERT() > triggers? I'm afraid I don't have an easy way to test it. The TNF testbed does not have an easy way of testing patches, I can't do

Re: ffs_newvnode: inode has non zero blocks

There was recenly change a change in FFS in the general area for WAPBL. Can you try attached patch and check if following KASSERT() triggers? 2016-11-02 18:39 GMT+01:00 Andreas Gustafsson : > co...@sdf.org wrote: >> I'm pretty 'abusive' to my machine. unsurprisingly, I've managed

Re: ffs_newvnode: inode has non zero blocks

co...@sdf.org wrote: > The lengthy problem description is not very important as it was fixed > I am just wondering about the setup of the tests, if there's a > possibility of bad data being left over (reuse of image, etc.) I don't think so; the image is not reused because the ATF framework runs

Re: ffs_newvnode: inode has non zero blocks

On Wed, Nov 02, 2016 at 10:50:51PM +0200, Andreas Gustafsson wrote: > co...@sdf.org wrote: > > There was recently an issue with resize_ffs mishandling a non zero > > filled expansion of FFSv2 (PR 51116). I wonder if this is similar. > > > > i.e., does zeroing out the disk help? > > If I read the

Re: ffs_newvnode: inode has non zero blocks

co...@sdf.org wrote: > There was recently an issue with resize_ffs mishandling a non zero > filled expansion of FFSv2 (PR 51116). I wonder if this is similar. > > i.e., does zeroing out the disk help? If I read the code of the test case correctly, it involves growing a file system image stored

Re: ffs_newvnode: inode has non zero blocks

On Wed, Nov 02, 2016 at 07:39:01PM +0200, Andreas Gustafsson wrote: > > The strange thing is that this problem seems to have started soon > after your report, not before it as I would expect if it were also the > cause of your crash. The filesystems involved are all newly created > in each test

Re: ffs_newvnode: inode has non zero blocks

co...@sdf.org wrote: > I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to > accumulate a problem: > > ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero blocks > 980 or size 0 > panic: ffs_newvnode: dirty filesystem? The TNF sparc testbed recently started

Re: ffs_newvnode: inode has non zero blocks

co...@sdf.org writes: >I do appear to have some franken-filesystem, half FFSv2, half FFSv1. >file system: /dev/rwd0a >format FFSv1 >endian little-endian >magic 11954 timeSat Oct 29 21:16:21 2016 >superblock location 8192id [ 56f77746 7e87473b ] >cylgrp dynamic

Re: ffs_newvnode: inode has non zero blocks

On Sat, Oct 29, 2016 at 06:06:18PM +, Christos Zoulas wrote: > In article <20161029175845.ga6...@sdf.org>, wrote: > >Hi, > > > >I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to > >accumulate a problem: > > > > ffs_newvnode: ino=20681997 on /: gen

Re: ffs_newvnode: inode has non zero blocks

In article <20161029175845.ga6...@sdf.org>, wrote: >Hi, > >I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to >accumulate a problem: > > ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero >blocks 980 or size 0 > panic: ffs_newvnode: dirty

ffs_newvnode: inode has non zero blocks

Hi, I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to accumulate a problem: ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero blocks 980 or size 0 panic: ffs_newvnode: dirty filesystem? It appears that fsck is not able to clear it. Do you we have a