Date: Mon, 29 Jul 2002 19:13:42 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: fs@freebsd.org, guptar@cs.rpi.edu Subject: Re: UFS Journaling Project Message-ID: <Pine.NEB.3.96L.1020729190915.46084A-100000@fledge.watson.org> In-Reply-To: <200207291714.g6THESc08188@jenolen.cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jul 2002, David E. Cross wrote: > As some of you know "we" (CS Dept lab) are working on a UFS journal. > We've made decent progress so far (given we've never worked on this part > of the code so far), but we've hit a block. We need to store state > information in the kernel... current journal offset, journal vnode, etc. > It seems the logical place to put this is in struct ufsmount (since each > mount will have different state), but whenever we put a "struct > ufsjournal *uj;" in we get corruptined inode messages; we have rebuilt > kernel from nothing. It seems that there are 2 copies of struct > ufsmount, or something is using raw offsets. > > Question: How do we modify struct ufsmount without causing corruption, > or where should we store a pointer to our state information? That's fairly odd. When I added extended attribute support to UFS, I simply stuck the new structure (ufs_extattr_per_mount) in struct ufsmount and never looked back. I can't, offhand, imagine what you're running into -- ufsmount should only ever be in-memory, and never on disk. Not sure I really have any useful suggestions, other perhaps than to experiment a bit and see what exactly triggers the problem. Try adding long[] arrays at various points in the structure, and see what size and location cause the problem to kick in. Very strange... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020729190915.46084A-100000>