Christoph Anton Mitterer posted on Sat, 12 Dec 2015 03:32:57 +0100 as
excerpted:
> [B]etter said I largely rewrote:
> https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes
> which I think should rather be its own wiki article.
>
> One of the devs/experts... please double check it and
On Wed, 2015-12-09 at 10:53 +, Duncan wrote:
> If you use the recipe (subvol create, cp with reflink) it suggests
> there,
> you'll end up with the reflinked copy in a subvol.
>
> You can then mount that subvol over top of the existing dir, and
> *new*
> file opens will access the new
On Sat, 2015-12-12 at 03:32 +0100, Christoph Anton Mitterer wrote:
> What's still missing now, IMHO, is:
> - a guide when one should make subvole (e.g. keeping things on the
> root
> fs together, unless it's separate like /var/www is usually, but
> /var/lib typically "corresponds" to a state of
On 2015-12-09 22:56, Duncan wrote:
> Austin S Hemmelgarn posted on Wed, 09 Dec 2015 14:04:06 -0500 as
> excerpted:
>
>> Agreed. It's not too bad fixing a Gentoo system (as long as
>> /var/lib/portage/world is still correct, you can just nuke the installed
>> package database and emerge world,
Christoph Anton Mitterer posted on Wed, 09 Dec 2015 05:36:37 +0100 as
excerpted:
> On Fri, 2015-11-27 at 01:02 +, Duncan wrote:
> [snip snap]
>> #2 The point I was trying to make, now, to mount it you'll mount not a
>> native nested subvol, and not a directly available sibling
>>
Christoph Anton Mitterer posted on Wed, 09 Dec 2015 05:38:02 +0100 as
excerpted:
> On Fri, 2015-11-27 at 02:02 +, Duncan wrote:
>> Consider a setuid-root binary with a recently publicized but patched on
>> your system vuln. But if you have root snapshots from before the patch
>> and those
On 2015-11-27 03:02, Duncan wrote:
>>> Then there's the security angle to consider. With the (basically,
>>> possibly modified as I suggested) flat layout, mounting something
>>> doesn't automatically give people in-tree access to nested subvolumes
>>> (subject to normal file permissions, of
On 2015-12-09 05:53, Duncan wrote:
> Christoph Anton Mitterer posted on Wed, 09 Dec 2015 05:36:37 +0100 as
> excerpted:
>
>> On Fri, 2015-11-27 at 01:02 +, Duncan wrote:
>> [snip snap]
>>> #2 The point I was trying to make, now, to mount it you'll mount not a
>>> native nested subvol, and not
On Fri, 2015-11-27 at 02:02 +, Duncan wrote:
> Uhm, I don't get the big security advantage here... whether nested
> > or
> > manually mounted to a subdir,... if the permissions are insecure
> > I'll
> > have a problem... if they're secure, than not.
> Consider a setuid-root binary with a
On Fri, 2015-11-27 at 01:02 +, Duncan wrote:
[snip snap]
> #1 could be a pain to setup if you weren't actually mounting it
> previously, just relying on the nested tree, AND...
>
> #2 The point I was trying to make, now, to mount it you'll mount not
> a
> native nested subvol, and not a
Christoph Anton Mitterer posted on Tue, 24 Nov 2015 22:25:50 +0100 as
excerpted:
>> Suppose you only want to rollback /, because some update screwed you
>> up,
>> but not /home, which is fine. If /home is a nested subvolume, then
>> you're now mounting the nested home subvolume from some other
Christoph Anton Mitterer posted on Tue, 24 Nov 2015 22:25:50 +0100 as
excerpted:
>> Then there's the security angle to consider. With the (basically,
>> possibly modified as I suggested) flat layout, mounting something
>> doesn't automatically give people in-tree access to nested subvolumes
>>
On Tue, 2015-11-24 at 21:55 +, Hugo Mills wrote:
> In practice, new content is checked by a number of people when
> it's
> put in, so the case of someone putting random poorly-thought-out crap
> in the wiki isn't particularly likely to happen.
Well... it may work in 99% cases... but there
On Tue, 2015-11-24 at 23:30 +, Hugo Mills wrote:
> Yes, that makes sense.
Feel free to shamelessly use my idea (as well as the one to call btrfs'
RAID1 replica2 or something else)
:-O
> With a recent mv
root@heisenberg:/mnt# mv --version
mv (GNU coreutils) 8.23
=> not recent enough...
On Wed, Nov 25, 2015 at 12:20:09AM +0100, Christoph Anton Mitterer wrote:
> On Tue, 2015-11-24 at 21:55 +, Hugo Mills wrote:
> > In practice, new content is checked by a number of people when
> > it's
> > put in, so the case of someone putting random poorly-thought-out crap
> > in the wiki
On Tue, 2015-11-24 at 08:29 +, Duncan wrote:
> OK, found it on the wiki. It wasn't under use-cases, where I
> initially
> thought to look, but under sysadmin guide. Specifically, see section
> 4.2, managing snapshots, but I'd suggest reading the entire
> subvolumes
> discussion, section 4,
On Tue, Nov 24, 2015 at 10:25:50PM +0100, Christoph Anton Mitterer wrote:
> On Tue, 2015-11-24 at 08:29 +, Duncan wrote:
> > OK, found it on the wiki. It wasn't under use-cases, where I
> > initially
> > thought to look, but under sysadmin guide. Specifically, see section
> > 4.2, managing
Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:56:00 +0100 as
excerpted:
> When I use subvolumes than these have always a parent subvolume (except
> ID5), so I can basically decide between two ways:
>
> a) make child subvolumes, e.g.
> 5
> |
> +-root (=subvol, mountpoint /)
> +-boot/
Hey.
I'd have a, mainly administrative, question.
When I use subvolumes than these have always a parent subvolume (except
ID5), so I can basically decide between two ways:
a) make child subvolumes, e.g.
5
|
+-root (=subvol, mountpoint /)
+-boot/
+-root/
+-lib/
+-home/ (=subvolume)
and
19 matches
Mail list logo
