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.
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
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
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...
>
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
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
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
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
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.
--
