On Thu, Dec 27, 2001 at 02:34:40AM -0600, Kevin Day wrote:

You might want to file this as a PR (using send-pr)
so that it can be looked at by the filesystem gurus. I am not to sure
that Kirk keeps up with -hackers

Wilko


> I think I've found a bug in fsck. Some invalid values in cylinder groups
> don't get fixed.
> 
> >From pass5.c:
> 
>                 if (cg->cg_rotor < newcg->cg_ndblk)
>                         newcg->cg_rotor = cg->cg_rotor;
>                 else
>                         newcg->cg_rotor = 0;
>                 if (cg->cg_frotor < newcg->cg_ndblk)
>                         newcg->cg_frotor = cg->cg_frotor;
>                 else
>                         newcg->cg_frotor = 0;
>                 if (cg->cg_irotor < newcg->cg_niblk)
>                         newcg->cg_irotor = cg->cg_irotor;
>                 else
>                         newcg->cg_irotor = 0;
> 
> 
> All those values in the cg's are int32_t's. (signed). Somehow I ended up
> with 5 cyl groups that have "irotor" to some random negative value. fsck
> doesn't see a problem with them, but I get a panic when a create gets
> called:
> 
>  #5  0xc0207e6b in trap (frame={tf_fs = -1072234480, tf_es = -345702384, tf_ds = 
>-1072234480, tf_edi = -750092288, tf_esi = -955801600, 
>        tf_ebp = -345663052, tf_isp = -345663072, tf_ebx = 177188131, tf_edx = 
>-750091519, tf_ecx = 255, tf_eax = -927279650, tf_trapno = 12, 
>        tf_err = 0, tf_eip = -1071824083, tf_cs = 8, tf_eflags = 66183, tf_esp = 
>-345663008, tf_ss = -1071971432}) at ../../i386/i386/trap.c:448
>  #6  0xc01d432d in skpc (mask0=255, size=177188131, cp0=0xc8bad5de <Address 
>0xc8bad5de out of bounds>) at ../../libkern/skpc.c:50
>  #7  0xc01b0398 in ffs_nodealloccg (ip=0xc7cb6300, cg=6921, ipref=27906609, 
>mode=33188) at ../../ufs/ffs/ffs_alloc.c:1347
>  #8  0xc01af567 in ffs_hashalloc (ip=0xc7cb6300, cg=6921, pref=27906609, size=33188, 
>allocator=0xc01b0258 <ffs_nodealloccg>)
>      at ../../ufs/ffs/ffs_alloc.c:863
>  #9  0xc01aeffc in ffs_valloc (pvp=0xebe8d980, mode=33188, cred=0xc77fd584, 
>vpp=0xeb659a5c) at ../../ufs/ffs/ffs_alloc.c:607
>  #10 0xc01c1b0f in ufs_makeinode (mode=33188, dvp=0xebe8d980, vpp=0xeb659c64, 
>cnp=0xeb659c78) at ../../ufs/ufs/ufs_vnops.c:2097
>  #11 0xc01bf4c4 in ufs_create (ap=0xeb659bfc) at ../../ufs/ufs/ufs_vnops.c:194
> 
> Here's the cyl group:
> 
> $2 = {cg_firstfield = 0, cg_magic = 590421, cg_time = 1009434417, cg_cgx = 9165, 
>cg_ncyl = 16, cg_niblk = 4032, cg_ndblk = 32768, cg_cs = {
>     cs_ndir = 60, cs_nbfree = 2740, cs_nifree = 1987, cs_nffree = 679}, cg_rotor = 
>1288, cg_frotor = 5112, cg_irotor = -2036988557, 
>   cg_frsum = {0, 80, 153, 45, 14, 5, 7, 5}, cg_btotoff = 168, cg_boff = 232, 
>cg_iusedoff = 264, cg_freeoff = 768, cg_nextfreeoff = 5436, 
>   cg_clustersumoff = 4860, cg_clusteroff = 4924, cg_nclusterblks = 4096, cg_sparecon 
>= {0 <repeats 13 times>}, cg_space = "\016"}
> 
> 
> Notice cg_irotor is completely out of whack, but fsck thinks the FS is
> clean.
> 
> I wrote a patch that made fsck detect this, but... why are these signed
> values anyway, other than historical reasons?
> 
> -- Kevin
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
---end of quoted text---

-- 
|   / o / /_  _                 email:  [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte         Arnhem, The Netherlands 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to