Phillip, thanks for the detailed message.
We are using NFS-mounted squashfs without problems, though I don't
know if we're exercising things to the point that the kernel would
have to flush parts of the dentry cache. Thanks for the heads up on
that one; I'll be on the lookout for stale NFS file handles.
Please let me (via this list) know at the point you are looking for
support for putting squashfs into the kernel. I will write a
description of why we think squashfs is great and should be included.
On 4/18/06, Phillip Lougher <phillip.lougher@...> wrote:
> On 4/16/06, Kenneth Duda <kduda@...> wrote:
> > Hi folks,
> > This patch fixes a bug in Squashfs-3.0.
> Thanks for the bug report and the patch.
> This is one of the wierd cases where you realise there's been a bug in
> Squashfs since the first release, but because it's always worked, you
> never knew about it!
> I based the original VFS interface code on ROMFS (way back in 2001
> this was the easiest filesystem to use to understand the VFS
> interface), which returned the number of directory entries read in
> readdir. A quick check against some other filesystems in the latest
> 2.6 kernel proves they always return 0 unless an error occurs. ROMFS
> in the latest kernel still returns the number of entries read, which
> is now obviously wrong.
> I'll fix readdir to always return 0 unless an error occurs.
> On a related note regarding NFS, I've previously received error
> reports that NFS didn't work with Squashfs. I've always supposed this
> was because Squashfs wasn't an "exportable filesystem" (i.e.
> implements the interface described in
> Documentation/filesystems/Exporting). My revised belief is the
> fundamental reason why Squashfs doesn't work with NFS is the bug
> you've found. However, to fully support NFS Squashfs must implement
> the interface described in the Exporting document. Without this
> support, once the server (exporting the Squashfs filesystem) flushes
> its dentry cache, any clients with handles on exported Squashfs files
> cannot map these back to Squashfs inodes on the server.
> NFS along with extended attributes is the last two things which I've
> not had time to get implemented in Squashfs. This time last year I
> thought it was time to look at these things, but (after the failed
> attempt to get Squashfs merged into the mainline kernel), I ended up
> with the need to extend the filesystem beyond 4GB, support hardlinks
> and "." and ".." entries. These unfortunately took priority over NFS
> and extended attributes which, after a year's rewriting, I'm intending
> to start work on now.
> So, I'm about to start work on NFS, which means your bug report/patch
> has been very helpful. I've got some work on parallelising mksquashfs
> to finish (some people brought up the valid points that mksquashfs
> didn't scale on SMP), but NFS work will hopefully start soon.
> > I hope this is helpful. Please let me know if there's anything I can
> > do to ease this patch's acceptance into the squashfs mainline.
> I intend to try to re-submit Squashfs once I have support for NFS.
> The major help regarding acceptance would be emails to the relevant
> kernel maintainer(s) urging acceptance when I've re-submitted it. I
> got a couple of emails of support on the LKML (Linux Kernel Mailing
> List) on the previous attempt, but it's clear from my previous
> experience the more support there is the better. Unfortunately,
> technical merit alone doesn't seem to be sufficient to get something
> accepted anymore, they also want to know why it should be accepted.
> Simply saying "because it's a nice thing to have" didn't seem to get
> very far last time :-) Unfortunately, the linux kernel is bloated,
> and no-one wants to add to the bloat anymore, that's my impression