lkml.org 
[lkml]   [2004]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] cowlinks v2
    Hi!

    > > Of course, it gets more interesting if you try to do it at the block
    > > level instead of at the file level. For ext2, you could just reserve
    > > a block #, say -1, to mean take the data from the master cow file, and
    > > anything else is treated normally. You would need a deamon to make
    > > sure you were still saving space though.
    >
    > More interesting is correct. I see the advantages and proposed this
    > myself some time ago, but there are downsides. Basically, for each
    > block you need additional data, at least a counter telling you the
    > number of users it currently has. Eats up memory.
    >
    > If it really has to make sense, you also have to detect duplicated
    > blocks at runtime. So you need a checksum for each block and a
    > balanced tree containing those checksums or some other means of quick
    > access. Eats up 40 bytes (16 checksum, 3*8 tree pointers). With 4k
    > blocks, that's 1% memory overhead.

    Well, you could do this in userspace, do it only if system is idle,
    and use "scan" type approach.

    But I agree that's far away.

    BTW what about the "mix hardlinks with cowlinks" proposal? You said it
    leads to hell and then I did not hear from you. Did it scare you that
    much? ;-)
    Pavel
    --
    When do you have a heart between your knees?
    [Johanka's followup: and *two* hearts?]
    -
    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:02    [W:0.022 / U:88.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site