On 2/14/06, Tomas M <[EMAIL PROTECTED]> wrote: > Finally I tried latest unionfs cvs version with squashfs 2.2 + SMP+ACPI > enabled kernel 2.6.15.4 > Works like a charm. So it is problematic only with squashfs 3.0pre.
If this is the case, then there could be a bug in Squashfs 3.0. I, therefore, have a couple of questions: 1. The kernel code is 3.0pre, but are you using a Squashfs 2.2 or 3.0 filesystem (i.e. what version of mksquashfs are you using)? 2. All the kernel dumps show the kernel is panicing in the 'read fragment' data path. This is probably coincidental as this data-path is used for files less than 64K, and most files are probably like that. However, to rule out a bug in that data-path, the Squashfs filesystem could be built with no fragments (-no-fragments option on mksquashfs). This will force the kernel Squashfs code to always use the non fragment data-path. The use of no fragments will cause worse compression, and therefore the filesystem may not fit onto a CD. If it does, however, then any result (no crash, or still crashing) will be very useful. Thanks Phillip > > So my result is following: > > - unionfs doesn't work good with squashfs3pre on SMP machines. > > If I understand it correctly, the main difference between squashfs 2.2 > and 3.0 is that > squashfs 3.0 now supports big filesystem (264 bytes), implements > hardlinks somehow > and stores inode numbers somewhere instead of computing them. > > Could the problem be caused by unionfs? > Is it possible that these changes could confuse unionfs somehow? > > > Thank you very much for your consideration. > > Tomas M > > > _______________________________________________ > unionfs mailing list > [email protected] > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs > _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
