On Thu, 19 Mar 2015 07:18:29 AM Erkki Seppala wrote:
> > But as a user level facility, I want to be able to snapshot before
> > making a change to a tree full of source code and (re)building it all
> > over again. I may want to keep my new build, but I may want to flush
> > it and return to known
On Fri, 20 Mar 2015 04:18:38 AM Duncan wrote:
> If cp --reflink=auto was the default, it'd "just work", making a reflink
> where possible, falling back to a normal copy where not possible to
> reflink.
>
> However, I'd be wary of such a change, because admins are used to cp
> creating a separat
Chris Murphy posted on Thu, 19 Mar 2015 13:09:06 -0600 as excerpted:
> Erkki's cp --reflink idea is a good one. I've often wondered if it's a
> good idea, and possible, to eventually make --reflink the default
> behavior with Btrfs copies (I think some things probably first need
> enhancement like
On Wed, Mar 18, 2015 at 5:22 PM, K Richard Pixley
wrote:
> Most of the uses I have for btrfs involve fairly dynamic use of snapshots,
> typically by non-root users.
Another thing. Some distros behave this way:
chris@linux-6gc0:~> btrfs sub list /
Absolute path to 'btrfs' is '/usr/sbin/btrfs', so
K Richard Pixley writes:
> But as a user level facility, I want to be able to snapshot before
> making a change to a tree full of source code and (re)building it all
> over again. I may want to keep my new build, but I may want to flush
> it and return to known good state.
You may want to check
On Wed, Mar 18, 2015 at 6:47 PM, Jeff Mahoney wrote:
> We use this layout in SLES too and it's necessary for both compliance
> and principle-of-lease-surprise purposes in concert with our
> snapshot-rollback facility.
I understand the logic, I'm just not convinced it's the only way to
achieve tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/18/15 7:33 PM, Chris Murphy wrote:
> On Wed, Mar 18, 2015 at 5:01 PM, K Richard Pixley
> wrote:
>
>> My complaint is a) about multiple subvols and b) about an
>> unnecessary and redundant subvol for the top level file system.
>
> The current g
On Wed, Mar 18, 2015 at 5:22 PM, K Richard Pixley
wrote:
> Most of the uses I have for btrfs involve fairly dynamic use of snapshots,
> typically by non-root users. That's what brought me to btrfs in the first
> place and continues to be the biggest driver for me.
By default, none privileged user
On Wed, Mar 18, 2015 at 5:01 PM, K Richard Pixley
wrote:
> My complaint is a) about multiple subvols and b) about an unnecessary and
> redundant subvol for the top level file system.
The current granularity supplied by root and home subvolumes is minor.
Eventually there'd also be a boot subvolum
On 3/18/15 15:15 , Chris Murphy wrote:
On Wed, Mar 18, 2015 at 3:39 PM, K Richard Pixley
wrote:
Ah! Thank you. That's the piece I was missing.
IMO, someone needs to take a clue-by-four to the heads of the
Fedora/RHEL/CentOS installer folks. I see no reason for this with btrfs.
Other than
On 3/18/15 14:55 , Hugo Mills wrote:
On Wed, Mar 18, 2015 at 02:39:26PM -0700, K Richard Pixley wrote:
On 3/18/15 14:06 , Chris Murphy wrote:
The Fedora/RHEL/CentOS installer creates two subvolumes: root and
home. If you check out fstab, those subvolumes are mounted at /
and /home. Therefore th
On Wed, Mar 18, 2015 at 3:39 PM, K Richard Pixley
wrote:
> Ah! Thank you. That's the piece I was missing.
>
> IMO, someone needs to take a clue-by-four to the heads of the
> Fedora/RHEL/CentOS installer folks. I see no reason for this with btrfs.
Other than the technical reasons Hugo mentions
On Wed, Mar 18, 2015 at 02:39:26PM -0700, K Richard Pixley wrote:
> On 3/18/15 14:06 , Chris Murphy wrote:
> >The Fedora/RHEL/CentOS installer creates two subvolumes: root and
> >home. If you check out fstab, those subvolumes are mounted at /
> >and /home. Therefore the top level subvolume (id 5) i
On 3/18/15 14:06 , Chris Murphy wrote:
The Fedora/RHEL/CentOS installer creates two subvolumes: root and
home. If you check out fstab, those subvolumes are mounted at / and
/home. Therefore the top level subvolume (id 5) is not mounted by
default, so there's no way to delete subvolumes in the t
On Wed, Mar 18, 2015 at 01:42:55PM -0700, K Richard Pixley wrote:
> I'm having trouble deleting a subvolume.
>
> [root@new-alfred ~]# uname -a
> Linux new-alfred.corp.graphitesystems.com 3.10.0-123.el7.x86_64 #1
> SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> [root@new-alfred ~]
On Wed, Mar 18, 2015 at 2:42 PM, K Richard Pixley
wrote:
> I'm having trouble deleting a subvolume.
>
> [root@new-alfred ~]# uname -a
> Linux new-alfred.corp.graphitesystems.com 3.10.0-123.el7.x86_64 #1 SMP Mon
If highly recommend that you check out elrepo.org for a newer kernel
than this. Curren
I'm having trouble deleting a subvolume.
[root@new-alfred ~]# uname -a
Linux new-alfred.corp.graphitesystems.com 3.10.0-123.el7.x86_64 #1 SMP
Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@new-alfred ~]# btrfs --version
Btrfs v3.16.2
[root@new-alfred ~]# btrfs fi show
Labe
17 matches
Mail list logo
