>Number:         612
>Category:       kern
>Synopsis:       a chikago disk mounted as dosfs can deadlock the kernel
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    gnats-admin (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec  5 10:05:03 1994
>Originator:     Martin Husemann
>Organization:
private
>Release:        1.0
>Environment:

System: NetBSD euterpe.owl.de 1.0 NetBSD 1.0 (EUTERPE) #0: Wed Nov 16 13:08:17 MET 1994 root@euterpe.owl.de:/usr/src/sys/arch/i386/compile/EUTERPE i386
Also tested (same effect) on a current kernel from yesterday's sup.

>Description:

I accidently inserted a 1.44MB Chikago disk and mounted it with "-t dosfs".
After some work (including rm -rf of a subtree on the disk that contains
directories and files with long names, which failed, of course) I copied  a
600 kB file to the disk. This never finished and I couldn't log in on other
term's (I could type the login name and ENTER, but then nothing would happen).

Microsoft claims it's new filesystem internals are compatible (and
transparent) to  low-level utilities which are not aware of Chikago changes
if they don't play fsck-games.

>How-To-Repeat:
	I'll investigate further, I'm not sure yet.

>Fix:
	None known (yet).
	Maybe the chikago file system changes should be integrated
	into dosfs?

	Can anybody point me to papers describing the new dosfs'
	internal structure? I only found a white paper describing
	the changes from the user level (long names are aliased similar
	to Sun's PC-NFS).
>Audit-Trail:
>Unformatted: