New loopback bug

I've encountered a loopback bug on kernel-2.4.3+international_patch. I haven't been able to pin down what the bug is exactly, but these are the conditions under which it manifests: 1. connect file to loopback device 2. build fs on loopback device 3. mount fs and use it 4. read the file 5.

New loopback bug

I've encountered a loopback bug on kernel-2.4.3+international_patch. I haven't been able to pin down what the bug is exactly, but these are the conditions under which it manifests: 1. connect file to loopback device 2. build fs on loopback device 3. mount fs and use it 4. read the file 5.

Re: 2.4.1 loopback FS partial fix

Excellent - this solved my problems. I stress tested the loopback device with a big copy and it seemed to work. I also made losetup use open64: [root@crush mount]# diff lomount.c lomount.c~ 230c230 < if ((ffd = open64 (file, mode)) < 0) { --- > if ((ffd = open (file, mode)) < 0) {

2.4.1 loopback bug

There seems to be a heisenbug embedded in the 2.4 loopback driver. The symptom is that at some point a kernel call just fails to return. I've tried to reduce this to the simplest possible example and came up with the following trace for a generic 2.4.1 kernel. [root@crush jl]# ls -l bigrandom

2.4.1 loopback bug

There seems to be a heisenbug embedded in the 2.4 loopback driver. The symptom is that at some point a kernel call just fails to return. I've tried to reduce this to the simplest possible example and came up with the following trace for a generic 2.4.1 kernel. [root@crush jl]# ls -l bigrandom

Re: 2.4.1 loopback FS partial fix

Excellent - this solved my problems. I stress tested the loopback device with a big copy and it seemed to work. I also made losetup use open64: [root@crush mount]# diff lomount.c lomount.c~ 230c230 if ((ffd = open64 (file, mode)) 0) { --- if ((ffd = open (file, mode)) 0) { and