cvs commit: src/sys/fs/hpfs hpfs_vnops.c src/sys/fs/msdosfs
msdosfs_denode.c src/sys/fs/ntfs ntfs_vnops.c src/sys/fs/nwfs
nwfs_node.c src/sys/fs/smbfs smbfs_node.c src/sys/fs/udf
udf_vnops.c src/sys/isofs/cd9660 cd9660_node.c src/sys/nfsclient ...
Alexander at Leidinger.net
Tue Jan 17 13:50:39 PST 2006
On Tue, 17 Jan 2006 17:29:03 +0000 (UTC)
Alfred Perlstein <alfred at FreeBSD.org> wrote:
> alfred 2006-01-17 17:29:03 UTC
> FreeBSD src repository
> Modified files:
> sys/fs/hpfs hpfs_vnops.c
> sys/fs/msdosfs msdosfs_denode.c
> sys/fs/ntfs ntfs_vnops.c
> sys/fs/nwfs nwfs_node.c
> sys/fs/smbfs smbfs_node.c
> sys/fs/udf udf_vnops.c
> sys/isofs/cd9660 cd9660_node.c
> sys/nfsclient nfs_node.c
> I ran into an nfs client panic a couple of times in a row over the
> last few days. I tracked it down to the fact that nfs_reclaim()
> is setting vp->v_data to NULL _before_ calling vnode_destroy_object().
> After silence from the mailing list I checked further and discovered
> that ufs_reclaim() is unique among FreeBSD filesystems for calling
> vnode_destroy_object() early, long before tossing v_data or much
> of anything else, for that matter. The rest, including NFS, appear
> to be identical, as if they were just clones of one original routine.
"Clones" as in identical and could be refactored into one function?
> The enclosed patch fixes all file systems in essentially the same
> way, by moving the call to vnode_destroy_object() to early in the
> routine (before the call to vfs_hash_remove(), if any). I have
> only tested NFS, but I've now run for over eighteen hours with the
> patch where I wouldn't get past four or five without it.
Do you think this panic can be triggered by e.g. letting rhytmbox run
over a lot of music files on 2 msdosfs partitions to update the music
It's not a bug, it's tradition!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
More information about the cvs-src