received here.
+1
jffs2 has a lzma kernel compressor patch for 2.6 based on the lzma
reference (7z?) source and lzo kernel compressor
On Wed, Mar 20, 2013 at 12:27 PM, Roger Pack wrote:
>
> Looks like this message was initially viewed as spam because of an
> HTML subpart...trying it again...
>
with lzo, and presumably lz4 the 128k extents of packed data are livable.
on bootable thumbdrive images esp. with merged metadata I think
favoring greater fragmentation vs. the current 128k would help, and
giving larger files momentum to occupy more than 128k extents would
also help.
On Wed, Mar 2
tried a git based backup? sounds spot-on as a compromise prior to
applying btrfs tweaks. snapshotting the git binaries would have the
dedupe characteristics.
On Mon, May 6, 2013 at 12:44 AM, Kai Krakow wrote:
> Jan Schmidt schrieb:
>
>>> I'm using an bash/rsync script[1] to backup my whole syst
if you have been waiting for a particular compressor to reach linux,
chances are it already has.
if you are slacking with btrfs and assuming someone will port your
favorite compression profile to a btrfs mount option someday, someone
has thought of that too, and that's already happened as well.
looks like ARM results are inconclusive, what about just plain STAGING
status for arm to let the android tweakers beat on it for a while?
they're full of bandwidth for the last mile performance observations
> >> There doesn't seem to be a significant difference between all three
> >> variants.
--
dunno if this thread is dead, but im inclined to patch in cp --reflink
to "fdupes" prog. It currently does provide a poor-man's dedupe via
md5sum and hardlink, or delete.
all the better if the distro-kernels can backport cross-snapshot
reflinks sooner than later.
On Sun, Apr 29, 2012 at 1:05 PM
On Mon, Aug 20, 2012 at 11:08 AM, Jérôme Poulin wrote:
>
> On Thu, Aug 16, 2012 at 5:41 PM, james northrup
> wrote:
> >
> > dunno if this thread is dead, but im inclined to patch in cp --reflink
> > to "fdupes" prog.
> > It currently does provide
more important, when will the emacs sendrecv.el be ready?
On Tue, Dec 4, 2012 at 9:29 PM, Ins wrote:
> Hello all,
>
> The implementation of send/receive is very cool.
>
> But I wonder whether there are any plans to support these features
> below or not,
>
> 1. support writable subvolu
common labels work for me on my 3 way raid volumes. there's been no problem.
what might be a problem is when i do mount LABEL=foo, btrfs dev scan
is not automatic on failure.
On Thu, Jan 3, 2013 at 9:01 AM, Hugo Mills wrote:
> On Thu, Jan 03, 2013 at 05:29:00PM +0100, Helmut Hullen wrote:
>> Ha
