lkml.org 
[lkml]   [2005]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][2/2] SquashFS
    Hi!

    > >>>Also, this filesystem seems to do the same thing as cramfs. We'd need to
    > >>>understand in some detail what advantages squashfs has over cramfs to
    > >>>justify merging it. Again, that is something which is appropriate to the
    > >>>changelog for patch 1/1.
    > >>
    > >>Well, probably Phillip can answer this better than me, but the main
    > >>differences that affect end users (and that is why we are using SquashFS
    > >>right now) are:
    > >> CRAMFS SquashFS
    > >>
    > >>Max File Size 16Mb 4Gb
    > >>Max Filesystem Size 256Mb 4Gb?
    > >
    > >
    > >So we are replacing severely-limited cramfs with also-limited
    > >squashfs...
    >
    > I think that's rather unfair, Squashfs is significantly better than
    > cramfs. The main aim of Squashfs has been to achieve the best

    Yes, it *is* rather unfair. Sorry about that. But having 2 different
    limited compressed filesystems in kernel does not seem good to me.

    > compression (using zlib of course) of any filesystem under Linux - which
    > it does, while also being the fastest. Moving beyond the 4Gb limit has
    > been a goal, but it has been a secondary goal. For most applications
    > 4Gb compressed (this equates to 8Gb or more of uncompressed data in most
    > usual cases) is ok.

    Okay, having limit on 4GB compressed is slightly better (and should
    mean that SquashFS would actually be usefull to me).

    > >For live DVDs etc 4Gb filesystem size limit will hurt for
    > >sure, and 4Gb file size limit will hurt, too. Can those be fixed?
    >
    > Almost everything can be fixed given enough time and money.
    > Unfortunately for Squashfs, I don't have much of either. I'm not paid
    > to work on Squashfs and so it has to be done in my free time. I'm hoping
    > to get greater than 4Gb support this year, it all depends on how much
    > free time I get.

    Well, out-of-tree maintainenance takes lot of time, too, so by keeping
    limited code out-of-kernel we provide quite good incentive to make
    those limits go away.

    Perhaps squashfs is good enough improvement over cramfs... But I'd
    like those 4Gb limits to go away.
    Pavel
    --
    People were complaining that M$ turns users into beta-testers...
    ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:11    [W:0.025 / U:2.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site