Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #197407 > unrolled thread

BTRFS and debian

Back to article view | Back to linux.debian.user

Contents

  BTRFS and debian Ge <gpdsbe@mailbox.org> - 2018-07-09 20:20 +0200
    Re: BTRFS and debian Matthew Crews <mailinglists@mattcrews.com> - 2018-07-09 21:40 +0200
      Re: BTRFS and debian Ulf Volmer <u.volmer@u-v.de> - 2018-07-09 22:00 +0200
        Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-09 23:00 +0200
          Re: BTRFS and debian Ulf Volmer <u.volmer@u-v.de> - 2018-07-09 23:10 +0200
        Re: BTRFS and debian Matthew Crews <mailinglists@mattcrews.com> - 2018-07-09 23:40 +0200
    Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-10 05:40 +0200
      Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-11 20:40 +0200
        Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-12 05:10 +0200
          Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-12 07:50 +0200
            Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-13 03:20 +0200
              Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-14 00:40 +0200
                Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 03:00 +0200
                  Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-14 11:10 +0200
                    Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 21:40 +0200
                      Re: BTRFS and debian Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-07-14 23:10 +0200
              Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 01:40 +0200
      Re: BTRFS and debian David Wright <deblis@lionunicorn.co.uk> - 2018-07-12 20:00 +0200
        Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-13 05:00 +0200
          Re: BTRFS and debian Dan Ritter <dsr@randomstring.org> - 2018-07-13 12:00 +0200
            Re: BTRFS and debian <tomas@tuxteam.de> - 2018-07-13 12:30 +0200
            Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 03:10 +0200
          Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 01:40 +0200
            Re: BTRFS and debian David Christensen <dpchrist@holgerdanske.com> - 2018-07-14 03:10 +0200
              Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 12:00 +0200
                Re: BTRFS and debian Reco <recoverym4n@gmail.com> - 2018-07-14 12:30 +0200
                  Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 12:40 +0200
                Wrapping lines, was Re: BTRFS and debian David Wright <deblis@lionunicorn.co.uk> - 2018-07-15 05:20 +0200
                  Re: Wrapping lines, was Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-15 05:30 +0200
                    Re: Wrapping lines, was Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-15 12:30 +0200
          Re: BTRFS and debian Zenaan Harkness <zenaan@freedbms.net> - 2018-07-14 11:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#197574

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 13, 2018 at 05:55:48AM -0400, Dan Ritter wrote:
> On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> > 
> > [Evi Nemeth, et al on cloud servers] when pets are
> > sick, you expend resources trying to heal them; when cattle are sick, you
> > shoot them [p. 272, fifth paragraph].
> 
> This is because you have many cattle doing the same things for
> you, whereas you have a unique relationship with each pet.

[...]

> Both cattle and pets continue to exist, because they serve
> different needs. The tools that enable cattle can allow you to 
> heal or resurrect a pet, but at a higher upfront cost.

Now what would be interesting is a sociological/anthropological
study on whether some people rather tend to pets and others
tend to cattle, and how cultural, psychological and other factors
influence that :-)

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAltIfaoACgkQBcgs9XrR2kY3JACeKPZtV2SZjvukIuIsPh6xSc49
t0QAn1UktWLhmTMcRQ/Uf6Hnm745CYRA
=id8P
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#197619

On 07/13/18 02:55, Dan Ritter wrote:
> The tools that enable cattle can allow you to
> heal or resurrect a pet, but at a higher upfront cost.

+1


David

[toc] | [prev] | [next] | [standalone]

#197616

On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> While a brutal analogy, it makes a point that can be applied to all
> computers -- devise strategies, invest in resources, and implement
> procedures that facilitate system roll-out, migration, and disaster
> recovery.  This is a goal I have pursued over the years.

zfs send (and of course filesystem snaphotting) ftw!
(I'm just learning about zfs btw, intending a home rollout in the
coming weeks.)

[toc] | [prev] | [next] | [standalone]

#197618

On 07/13/18 16:36, Zenaan Harkness wrote:
> On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
>> While a brutal analogy, it makes a point that can be applied to all
>> computers -- devise strategies, invest in resources, and implement
>> procedures that facilitate system roll-out, migration, and disaster
>> recovery.  This is a goal I have pursued over the years.
> 
> zfs send (and of course filesystem snaphotting) ftw!
> (I'm just learning about zfs btw, intending a home rollout in the
> coming weeks.)

ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the 
license keeps it out of Debian.  We'll see if and when btrfs catches up.


David

[toc] | [prev] | [next] | [standalone]

#197623

On Fri, Jul 13, 2018 at 05:59:58PM -0700, David Christensen wrote:
> On 07/13/18 16:36, Zenaan Harkness wrote:
> > On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> > > While a brutal analogy, it makes a point that can be applied to all
> > > computers -- devise strategies, invest in resources, and implement
> > > procedures that facilitate system roll-out, migration, and disaster
> > > recovery.  This is a goal I have pursued over the years.
> > 
> > zfs send (and of course filesystem snaphotting) ftw!
> > (I'm just learning about zfs btw, intending a home rollout in the
> > coming weeks.)
> 
> ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the license keeps it out of Debian.  We'll see if
> and when btrfs catches up.

(Do you know why your mail client (or perhaps server) wraps at 115
chars? 72 or 69 or even 80 would be much better...)

In stretch I see:

zfs-dracut zfs-dkms zfs-initramfs zfsutils-linux

however they're all in "contrib" rather than main.

Can someone explain if there's an -actual- non-free dependency that
these packages have, or if it is just the somewhat-incompatibility
between ZFS CDDL and Linux GPL?

Since at least zfs-fuse dispels the "is bound to Linux kernel" part.

TIA,

[toc] | [prev] | [next] | [standalone]

#197626

	Hi.

On Sat, Jul 14, 2018 at 07:50:03PM +1000, Zenaan Harkness wrote:
> Can someone explain if there's an -actual- non-free dependency that
> these packages have, or if it is just the somewhat-incompatibility
> between ZFS CDDL and Linux GPL?

Unless they manage to pull in some Oracle code (zfs encryption and
dtrace probes come to mind), ZFS on Linux is a free (as in freedom)
software.
But, since Sun Microsystems deliberately designed CDDL to be
incompatible with GPL2 (happened in 2004 IIRC), you can not ship ZFS
binary modules with the Linux kernel, for instance ([1]).
What you can do is to ship source code, and 'ask' the user to build such
modules for themselves (hence the need of dkms or module-assistant).

[1] https://github.com/zfsonlinux/zfs/wiki/FAQ

[toc] | [prev] | [next] | [standalone]

#197627

On Sat, Jul 14, 2018 at 01:19:39PM +0300, Reco wrote:
> 	Hi.
> 
> On Sat, Jul 14, 2018 at 07:50:03PM +1000, Zenaan Harkness wrote:
> > Can someone explain if there's an -actual- non-free dependency that
> > these packages have, or if it is just the somewhat-incompatibility
> > between ZFS CDDL and Linux GPL?
> 
> Unless they manage to pull in some Oracle code (zfs encryption and
> dtrace probes come to mind), ZFS on Linux is a free (as in freedom)
> software.
> But, since Sun Microsystems deliberately designed CDDL to be
> incompatible with GPL2 (happened in 2004 IIRC), you can not ship ZFS
> binary modules with the Linux kernel, for instance ([1]).
> What you can do is to ship source code, and 'ask' the user to build such
> modules for themselves (hence the need of dkms or module-assistant).
> 
> [1] https://github.com/zfsonlinux/zfs/wiki/FAQ

Yes, zfs-dkms and zfs-initramfs is a little more work that plain
apt install.

This gives some of the details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861263

which explains thusly:

 “> Forgive my ignorance, but why will it not happen?

  The legal status of ZFSonLinux was discussed by the FTP team and
  DPL over a long period, with input from legal counsel, resulting in
  a decision to put it in the 'contrib' section.  That decision is
  unlikely to be revisited soon.
 ”

and further from
https://blog.halon.org.uk/2016/01/on-zfs-in-debian/#comment-13678
:

 Martin (February 28, 2017 at 6:14 pm):
 > I understand the decision to distribute ZFS as source
 > only, but could you elaborate on why the package is
 > going into contrib rather than main?

 Neil McGovern (February 28, 2017 at 6:26 pm):
 > Sure – it’s about the promise that Debian makes to
 > the end user. Basically, by it being in main you’re
 > legally able to redistribute the end product (along with
 > source). With a CDDL module and a GPL2+ kernel,
 > that becomes – at best – unclear.


So, packages are even provided such as zfs-initramfs and zfs-dkms to
make the process largely painless, for which we be grateful.

[toc] | [prev] | [next] | [standalone]

#197643 — Wrapping lines, was Re: BTRFS and debian

On Sat 14 Jul 2018 at 19:50:03 (+1000), Zenaan Harkness wrote:
> On Fri, Jul 13, 2018 at 05:59:58PM -0700, David Christensen wrote:
> > On 07/13/18 16:36, Zenaan Harkness wrote:
> > > On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> > > > While a brutal analogy, it makes a point that can be applied to all
> > > > computers -- devise strategies, invest in resources, and implement
> > > > procedures that facilitate system roll-out, migration, and disaster
> > > > recovery.  This is a goal I have pursued over the years.
> > > 
> > > zfs send (and of course filesystem snaphotting) ftw!
> > > (I'm just learning about zfs btw, intending a home rollout in the
> > > coming weeks.)
> > 
> > ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the license keeps it out of Debian.  We'll see if
> > and when btrfs catches up.
> 
> (Do you know why your mail client (or perhaps server) wraps at 115
> chars? 72 or 69 or even 80 would be much better...)

Your own mail client is doing this. You need to find out how to set
the wrapping value. In mutt, you might add the line

set	reflow_wrap=80

to your configuration file. (Seems unlikely though, as your client
appears not to report itself, as mutt would do.)

What's actually contained in David's email is:

"ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the "
"license keeps it out of Debian.  We'll see if and when btrfs catches up."

(I put the quotation marks round each line.) Note the space at the end
of the first line, which indicates that the next line is a continuation
of this one.

Why is this happening? Because David's email header contains:

Content-Type: text/plain; charset=utf-8; format=flowed

It's the format=flowed that's making *your* email client reflow
the text as required, but unfortunately to ~115 character lines
rather than what you would prefer.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#197644 — Re: Wrapping lines, was Re: BTRFS and debian

On Sat, Jul 14, 2018 at 10:10:01PM -0500, David Wright wrote:
> On Sat 14 Jul 2018 at 19:50:03 (+1000), Zenaan Harkness wrote:
> > On Fri, Jul 13, 2018 at 05:59:58PM -0700, David Christensen wrote:
> > > On 07/13/18 16:36, Zenaan Harkness wrote:
> > > > On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> > > > > While a brutal analogy, it makes a point that can be applied to all
> > > > > computers -- devise strategies, invest in resources, and implement
> > > > > procedures that facilitate system roll-out, migration, and disaster
> > > > > recovery.  This is a goal I have pursued over the years.
> > > > 
> > > > zfs send (and of course filesystem snaphotting) ftw!
> > > > (I'm just learning about zfs btw, intending a home rollout in the
> > > > coming weeks.)
> > > 
> > > ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the license keeps it out of Debian.  We'll see if
> > > and when btrfs catches up.
> > 
> > (Do you know why your mail client (or perhaps server) wraps at 115
> > chars? 72 or 69 or even 80 would be much better...)
> 
> Your own mail client is doing this. You need to find out how to set
> the wrapping value. In mutt, you might add the line
> 
> set	reflow_wrap=80

Sweet!

Very informative. Daŋkə schön :)


> to your configuration file. (Seems unlikely though, as your client
> appears not to report itself, as mutt would do.)
> 
> What's actually contained in David's email is:
> 
> "ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the "
> "license keeps it out of Debian.  We'll see if and when btrfs catches up."
> 
> (I put the quotation marks round each line.) Note the space at the end
> of the first line, which indicates that the next line is a continuation
> of this one.
> 
> Why is this happening? Because David's email header contains:
> 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> It's the format=flowed that's making *your* email client reflow
> the text as required, but unfortunately to ~115 character lines
> rather than what you would prefer.
> 
> Cheers,
> David.
> 

[toc] | [prev] | [next] | [standalone]

#197649 — Re: Wrapping lines, was Re: BTRFS and debian

On Sun, Jul 15, 2018 at 01:23:36PM +1000, Zenaan Harkness wrote:
> On Sat, Jul 14, 2018 at 10:10:01PM -0500, David Wright wrote:
> > On Sat 14 Jul 2018 at 19:50:03 (+1000), Zenaan Harkness wrote:
> > > On Fri, Jul 13, 2018 at 05:59:58PM -0700, David Christensen wrote:
> > > > ZFS is killer technology.  zfs-fuse is sawed off.  ZOL rocks, but the license keeps it out of Debian.  We'll see if
> > > > and when btrfs catches up.
> > > 
> > > (Do you know why your mail client (or perhaps server) wraps at 115
> > > chars? 72 or 69 or even 80 would be much better...)
> > 
> > Your own mail client is doing this. You need to find out how to set
> > the wrapping value. In mutt, you might add the line
> > 
> > set	reflow_wrap=80
> 
> Sweet!
> 
> Very informative. Daŋkə schön :)

Ahh yes, now I remember, I set reflow_wrap to 69 originally, then
added the sidebar, and mutt has a bug where the sidebar width is
included in the reflow width. But some weeks (months?) ago I removed
the sidebar, so must again change reflow_wrap.

Thanks heaps,

[toc] | [prev] | [next] | [standalone]

#197621

On Thu, Jul 12, 2018 at 07:53:01PM -0700, David Christensen wrote:
> On 07/12/18 10:52, David Wright wrote:
> > On Mon 09 Jul 2018 at 20:33:00 (-0700), David Christensen wrote:
> > > On 07/09/18 11:17, Ge wrote:
> > > > Should i make a different partition for /home/ ?
> > > 
> > > I don't -- I put my bulk data on a file server, including all e-mail
> > > attachments.  My home directory is ~1 GB.
> > > 
> > > 
> > > (If/when I want to travel with my laptop, I will need to figure out
> > > how to set up a VPN to my file server.)
> > 
> > I would find that rather risky, so I have a "proper" separate,
> > encrypted /home that ranges from 50GiB (laptop) to ~400GiB
> > (desktops)—basically, the rest of the drive, though one laptop
> > gives a fair amount of space over to a W10 installation.
> 
> First, I will need to test how the applications I use react to VPN connections going up and down.
> 
> 
> My file server is also a CVS server.  This makes it easy to keep the same files on multiple computers, and to
> synchronize changes.  (CVS can solve the three-way merge problem for text files.  I need to be mindful when editing
> binary files.)

I've completely replaced CVS with git these days - for all my
hacking of course, as well as parts of home/ - and I finally figured
out how to have a inter-system (or -drive) "git update" work
"properly" by which I mean:

 - some repos I am interested in, I grab into home/setups-local with
   a quick
   git clone git://repo... repo.gits

 - Everything ultimately gets backed up onto a file server, on which
   when I'm working I grab a repo with
   git clone --mirror git://repo... repo.gitm

 - The repo.git[ms]/.git/configs need to do the following:

 a) in whichever repo I am in/ updating (by script or otherwise), I
 want a "git fetch" or "git pull" to Do The Right Thing (TM)(C)(R),
 which means:

 b) it MUST first get all possible updates from the "other" instance
 that I maintain of that repo, including my own personal branches etc

 c) only THEN must it download remaining updates from the net

and so to achieve this, the .git/config files look somewhat like
this:


# ~/setups-local/postgresql.gits/.git/config :

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
[remote "setups"]
  # fetch from "setups"
  url = /setups/p/postgresql/postgresql.gitm
  fetch = +refs/remotes/origin/*:refs/remotes/setups/*
[remote "origin"]
  url = git://github.com/trevorbernard/disruptor-examples.git
  fetch = +refs/*:refs/remotes/origin/*
  fetch = +refs/heads/*:refs/heads/*
  fetch = +refs/tags/*:refs/tags/*
[branch "master"]
  remote = origin
  merge = refs/heads/master



# /setups/p/postgresql/postgresql.gitm/config :

[core]
  repositoryformatversion = 0
  filemode = true
  bare = true
[remote "setups-local"]
  # fetch from "setups-local"
  url = /home/me/setups-local/postgresql.gits
  fetch = +refs/remotes/origin/*:refs/remotes/setups-local/*
[remote "origin"]
  url = git://git.postgresql.org/git/postgresql.git
  fetch = +refs/*:refs/remotes/origin/*
  fetch = +refs/heads/*:refs/heads/*
  fetch = +refs/tags/*:refs/tags/*
# fetch = +refs/pull/*:refs/remotes/origin/pull/*
# fetch = +refs/pull/*:refs/rpull/origin/*
[remote "pgxc-sf"]
  url = git://postgres-xc.git.sourceforge.net/gitroot/postgres-xc/postgres-xc
  fetch = +refs/heads/*:refs/remotes/pgxc-sf/*
  fetch = +refs/tags/*:refs/rtags/pgxc-sf/*
[remote "pgxc"]
  url = git://github.com/postgres-x2/postgres-x2.git
  fetch = +refs/heads/*:refs/remotes/pgxc/*
  fetch = +refs/tags/*:refs/rtags/pgxc/*
[remote "pgxc-docs"]
  url = git://github.com/postgres-x2/implementationDocs.git
  fetch = +refs/heads/*:refs/remotes/pgxc-docs/*
  fetch = +refs/tags/*:refs/rtags/pgxc-docs/*
[remote "pgxc-webpage"]
  url = git://github.com/postgres-x2/webpage.git
  fetch = +refs/heads/*:refs/remotes/pgxc-webpage/*
  fetch = +refs/tags/*:refs/rtags/pgxc-webpage/*
[remote "pgxc-github.io"]
  url = git://github.com/postgres-x2/postgres-x2.github.io.git
  fetch = +refs/heads/*:refs/remotes/pgxc-github.io/*
  fetch = +refs/tags/*:refs/rtags/pgxc-github.io/*
[remote "pgxl"]
  url = git://git.code.sf.net/p/postgres-xl/postgres-xl
  fetch = +refs/heads/*:refs/remotes/pgxl/*
  fetch = +refs/tags/*:refs/rtags/pgxl/*
[remote "pgxl-tools"]
  url = git://git.code.sf.net/p/postgres-xl/tools
  fetch = +refs/heads/*:refs/remotes/pgxl-tools/*
  fetch = +refs/tags/*:refs/rtags/pgxl-tools/*



In this way, I can update one, then update the other, and I don't
download the updates twice. Yes, each holds an extra set of heads,
tags etc under remotes/setups/ and remotes/setups-local/
respectively, which not only is a very small "price" to pay, but has
actually been useful once or twice when I've messed around with tags
and heads, gotten befuddled and ultimately had to go check the
local "origin" duplicate refs in setups or setups-local, to fix
things up.

This took me a few attempts, a coupla bungles and many googoyle
searches and man page readings, over a year and half, before I
finally got it right. The main problem (besides understanding enough
of remotes and refs) was duplicating the "other" mirror (setups and
setups-local respectively, in the above example) into the current
mirror, without building a deeper and deeper refs hierarchy due to
the inherently recursive tags hierarchy creation with something
simple such as:

[setups]
 fetch = +refs/*:refs/remotes/origin/*

[setups-local]
 fetch = +refs/*:refs/remotes/origin/*

which would cause an ever-deepening refs hierarchy each time I
swapped from one mirror to the other.

Using fetch = +refs/remotes/origin/*:refs/remotes/setups/* instead,
solves this particular problem - but also means one must add lines
such as the following:
  fetch = +refs/heads/*:refs/heads/*
  fetch = +refs/tags/*:refs/tags/*

in order for the repo to "work" normally.


Note also my "setups" mirror includes a bunch of other repos which
relate to postgresql - that way, common files are not duplicated
across many local mirrors, instead they're all in a single mirror -
this is particularly useful when one is mirroring various forks of a
large repo, such as Linux kernel. Use commands such as the following
to add an additional remote repo, to a local mirror:

git remote add <name> <url>

And then you can use <name> to checkout branches, or create work dirs
(a nice feature in recent versions of git).

Enjoy,

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web