from:"Shriramana Sharma"

IIUC df means disk free and is supposed to display the disk's (or
partition's) free space -- but while btrfs fi df displays the
allocated and used sizes, it doesn't actually display the total
capacity of the devices, and subtract the allocated size and display
the rest.

One should not need to run the additional (regular) df command to find
out that info, IMO.

Anyone have any objection to my submitting a bug requesting this
additional info to be printed?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

System/single + Metadata/single as leftover cruft of mkfs?

I observe that whenever I create a BtrFS instance using mkfs.btrfs,
there is always the leftover cruft of two System/Metadata-Single
allocation profiles:

btrfs fi df /run/media/samjnaa/BRIHATII/
Data, single: total=460.01GiB, used=458.47GiB
System, DUP: total=8.00MiB, used=80.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.50GiB, used=736.86MiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=256.00MiB, used=0.00B

Doing btrfs balance eventually removes these (but since I forgot to do
it *before* copying 400+ G of data to the drive it's still running)
but I don't understand why these have to be created in the first
place? (I just used SuSE Tumbleweed's default mkfs.btrfs without any
-m or -d options.)

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to undo subvol delete?

On Thu, Dec 4, 2014 at 12:23 AM, David Sterba dste...@suse.cz wrote:
 On Tue, Dec 02, 2014 at 08:45:10PM +0530, Shriramana Sharma wrote:
 On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote:
 
  Works for me without the root password on a Tumbleweed installation
  (without apparmor/selinux).

 Are you then referring to a btrfs partition mounted with 
 user_subvol_rm_allowed?

 The context was 'does creating a subvolume require root password'.

Well I don't know about you, but I'm just running an openSUSE 13.2
system updated to Tumbleweed here, and even if I just hit btrfs
enter (no sudo, no btrfs commands) on my regular (non-root) prompt, I
am getting:

$ btrfs
Absolute path to 'btrfs' is '/usr/sbin/btrfs', so running it may
require superuser privileges (eg. root).
$

... so what to say of btrfs subvol, whether followed by crea or del!

On Kubuntu Trusty, doing the above at least gives me the help list of
btrfs subcommands and only when I try to execute some actual *action*
which requires privileges (like accessing some root-read-only file or
such) do I get an error message for not using sudo. For some (wierd)
reason SuSE (possibly thinking it's being helpful) is requiring me to
use sudo and enter password for even just *running* the btrfs
executable. If there were a way to disable this and/or get the Kubuntu
behaviour it'd be great (but of course this is not a SuSE forum!).

What seems weird to me here is that it says it *may* require root
privileges but simply drops me back to the prompt -- it doesn't seem
to check whether the executable *actually* requires root permission.
Granted, if it's under /sbin or /ust/sbin, it probably does, but the
wording is quite strange, and the behaviour stranger.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: System/single + Metadata/single as leftover cruft of mkfs?

On Thu, Dec 4, 2014 at 7:43 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
 SuSE may have an old version of btrfs-progs then (which wouldn't surprise
 me, it is an 'enterprise' distribution after all), because I haven't seen
 this on anything since 3.16.

Well OK I kinda like the old name SuSE since that was the name I was
using back when I was on 9.3, but actually I'm running openSUSE
Tumbleweed. See:

$ btrfs --version
Btrfs v3.17+20141103

I suppose Tumbleweed should be short and clear enough for my future usage.

 Also, for future reference, you can use the switch -mprofiles=single to just
 balance out those chunks.

Wow, thanks, that returned quickly. (Thankfully I did btrfs bal from a
separate terminal can rather than ^C.)

BTW I thought you had unintentionally (for brevity) omitted the
-sprofiles=single and I gave it but it complained saying:

Refusing to explicitly operate on system chunks.
Pass --force if you really want to do that.

So I did give --force. (Is it the same as -f?)

I hope that was OK?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: System/single + Metadata/single as leftover cruft of mkfs?

On Thu, Dec 4, 2014 at 11:47 PM, Robert White rwh...@pobox.com wrote:

 If those disappeared, or got stripped off onto other drives then not-amusing
 things would happen.

Well after doing btrfs bal start path -mprofiles=single, the FS is
still working...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Thin metadata and nohole options recommended?

From what I'm reading, thin metadata and nohole options were
introduced to make the FS more efficient. Does this mean that for
someone about to do mkfs.btrfs, it is actively recommended to use
these options?

Another pertinent question -- why aren't they default then?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
N�r��yb�X��ǧv�^�)޺{.n�+{�n�߲)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: Moving an entire subvol?

On Tue, Dec 2, 2014 at 6:58 PM, David Sterba dste...@suse.cz wrote:

 A subvolume is also a snapshotting barrier, so it's convenient to create
 subvolumes in well-known paths that contain data that should not be
 rolled back (/var/log, /srv, bootloader).

Hi David -- a real honour to meet one of the core Btrfs/SuSE (heh,
when that was the spelling!) guys!

That makes sense. Is there anywhere that the official SuSE
recommended subvol layout is mentioned that I can refer to without
having to start up an installer? (I currently chose ext4 for / for
other reasons so I can't refer to my layout.)

I am now reading a SuSECon 2013 presentation by Nyers and Schnell but
they are very generic about the recommendations.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to undo subvol delete?

On Tue, Dec 2, 2014 at 6:26 PM, David Sterba dste...@suse.cz wrote:

 Works for me without the root password on a Tumbleweed installation
 (without apparmor/selinux).

Are you then referring to a btrfs partition mounted with user_subvol_rm_allowed?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
N�r��yb�X��ǧv�^�)޺{.n�+{�n�߲)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: Possible to undo subvol delete?

On Tue, Dec 2, 2014 at 12:41 PM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:

 Snapper can automatically take a snapshot just before
 taking/deleting snapshots. So, if you delete a snapshot
 by mistake, it's still alive.

Sorta contradicts the whole point of deleting a snapshot, no? Or is it
some sort of trash vs (real) delete mechanism?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thin metadata and nohole options recommended?

On Tue, Dec 2, 2014 at 10:30 PM, Zygo Blaxell
ce3g8...@umail.furryterror.org wrote:

 IMHO if an optional filesystem feature has had a significant bug fixed
 in the last six months, it probably shouldn't be enabled by default.  ;)

Excellent point. I noted that my SuSE Tumbleweed enables extref by
default but not any of the others. Is that a SuSE-specific
modification or upstream?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving an entire subvol?

On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills h...@carfax.org.uk wrote:

Is that correct: what btr sub list shows as top level is indeed the
parent subvolume?

No, it's the top-level subvolume. (See my earlier mail about
nomenclature). Parent subvolume has a number of meanings, none of
which should be the subvolume with subvolid 5.

Um I searched my inbox but didn't find a specific definition from you
for top-level. You only said it's better to avoid calling it root
to avoid confounding it with the subvol that may be mounted at root
i.e. /.

IIUC the top-level subvolume can only be subvolid 5 which accords
with your later comment:

that putting files in the top-level subvol can't do what most people
want to do with it. Hence the recommended subvol management layout at
[1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes

... which means that I am not able to understand the output of btr sub
list which gives the subvolid of whichever subvol is currently the
parent (as in outer nesting) subvol. Observe:

$ btr sub list .
ID 257 gen 10 top level 5 path test1
ID 258 gen 10 top level 5 path test2
ID 259 gen 9 top level 258 path test2/foo
$ sudo mv test2/foo test1/
$ btr sub list .
ID 257 gen 10 top level 5 path test1
ID 258 gen 10 top level 5 path test2
ID 259 gen 9 top level 257 path test1/foo
$

So now what is the meaning of top level?

--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Moving an entire subvol?

On Wed, Dec 3, 2014 at 2:43 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
 Here's my approach to things:

Wow, thanks a lot people! I'm really benefiting from your experience here.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Possible to undo subvol delete?

On Wed, Dec 3, 2014 at 5:41 AM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
 2. You delete /snap by snapper delete command by mistake.
Then snapper takes a pre snapshot just before deleting
/snap.
 3. Now /snap is deleted, however, a pre snapshot which is
the same as /snap before deleting, is still alive.

 I don't know how Btrfs itself undo the deletion of a snapshot.
 It works if you manages snapshots not by btrfs directly,
 but by snapper.

 If I misunderstanding something, sorry for noise.

No nothing misunderstood. Excellent illustration. So using snapper is
sorta like using the higher-level trash instead of lower-level rm, so
that even after we delete, it's still available...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to undo subvol delete?

On Mon, Dec 1, 2014 at 6:42 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:

 We might want to consider adding an option to btrfs subvol del to ask for
 confirmation (or make it do so by default and add an option to disable
 asking for confirmation).

I already reported: https://bugzilla.kernel.org/show_bug.cgi?id=89091.
As I requested there, I prefer for confirmation by default and -f to
force otherwise, rather than behaviour of rm which requires -i to ask
confirmation.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to undo subvol delete?

On Mon, Dec 1, 2014 at 7:16 PM, Roman Mamedov r...@romanrm.net wrote:

 A more sensible idea could be adding a global-level '-i' switch, same as in
 'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask
 confirmation on any irreversible action).

Well the difference being that there doesn't seem to be any other
irreversible action from my scan of man btrfs -- am I missing
anything? This is the only thing that actually leads to loss of data.

When btrfs has so many features (esp snapshots) to prevent user
accidentally deleting data (I liked especially
http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to
be *some* modicum of support for warning against deleting a subvolume
(and it seems others agree too).

But I see what you mean in the bugzilla comment about not wanting your
existing backup snapshot scripts to fail because they don't have a -f.
At the same time, aliasing via -i on top level btrfs binary may not be
so practical here because this is the only command which will actually
use it (again, correct if wrong).

Perhaps exporting some envvar in the default shell's rc file (or
whichever file will be read only if the shell is interactive) would
work? Like in ~/.bashrc:

export BTRFS_SUBVOLUME_DELETE_CONFIRM=1

Ideas?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to undo subvol delete?

On Mon, Dec 1, 2014 at 7:24 PM, MegaBrutal megabru...@gmail.com wrote:

 If you want to make snapshots which can't be removed by ordinary tools, use
 the 'read-only' mode when creating them.

 Yeah, good idea! Anyway, is it possible to change a read-only snapshot
 to read-write and vica-versa, or you can only specify read-only while
 creating them?

IIUC you can only specify RO while creating but you can always cheaply
create a RW snapshot of an RO one or an RO snapshot of an RW one...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving an entire subvol?

On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy li...@colorremedies.com wrote:
 But isn't it just possible to move i.e. reparent a
 subvol so I can move these two under another subvol and have that as
 default?

 You can move subvolumes.

OK so I just found out that just mv test1/foo test2/ where test1,
test2 and foo are all subvolumes is sufficient to reparent foo to
test2, if what btr sub list shows as top level is indeed the parent
subvolume.

Is that correct: what btr sub list shows as top level is indeed the
parent subvolume?

 My suggestion is subvolumes containing
 binaries shouldn't be located within another subvolume that ends up
 being mounted, that way old binaries with possible vulnerabilities
 aren't exposed in the normal search path.

I'm not sure what you mean. Are you saying that for example /usr/bin should be:

1) a separate subvolume than / or /usr,
2) not a child subvolume of / or /usr?

 openSUSE uses subvol id 5 for installing the OS to, and some
 directories are made subvolumes such as home var and maybe usr.
 Therefore when subvolid 5 is snapshot, those are exempt, and have to
 be individually snapshot.

Yes I also noticed that openSUSE creates such separate subvols, but is
there any particular benefit to making it so?

 Fedora uses subvolumes root and home by default, and fstab uses
 subvol=root and subvol=home to mount them at / and /home respectively.

This seems similar to Ubuntu's @ and @home setup.

Is there any advantage to either? That is, one model installs root to
the topmost subvol and makes usr, home etc nested subvols, whereas
another makes root a nested subvol under the topmost just like usr
home etc, and then mounts it to /...

In general it seems people (or at least distros) prefer avoiding
nesting subvolumes. Is there any particular reason for this? Esp in
regard to /usr etc it would seem that if they are nested within the
subvol for /, then just mounting that subvol would automatically mount
all nested subvolumes, right? So the extra effort needed to mount the
nested subvols would not be necessary, no?

Shriramana.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to undo subvol delete?

On Tue, Dec 2, 2014 at 8:44 AM, Zygo Blaxell
ce3g8...@umail.furryterror.org wrote:
 This is consistent with the
 way lvm2 and mdadm work when presented with data-losing or otherwise
 questionable commands and parameters.  It will break scripts, but btrfs
 users should still be expecting that for a while as undesirable default
 behaviors are identified.

Ah so there *is* precedent for my hunch that deleting subvols should
be different than deleting ordinary files and folders... :-)

 OTOH maybe there is no issue with the current behavior.  Only root can
 delete subvolumes, and maybe we assume root knows what they're doing?

Well in office environs, where the root password is with a certain
person only, then that's fine because that person is going to be wary
of doing anything that's make others angry at them, but on single-user
systems, one's regular password *is* the root password and the
situation is such that because ordinary (and mostly non-destructive)
things like installing requires entering it, so one gets accustomed to
entering it without too much thought, leading to the requirement for
such safety nets.

(Perhaps like in banks, we should have a two-password system, one for
destructive actions, so the user is forced to apply thought to what
they are approving!)

 On a side note...only root can delete subvolumes, but non-root users
 can create them, which results in...this:

Not sure about your Debian system, but my openSUSE Tumbleweed (with
kernel 3.17.2 and btrfsprogs 3.17) requires me to enter the root
password before creating a subvol (or in fact running anything under
/sbin or /usr/sbin).

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving an entire subvol?

On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN m...@merlins.org wrote:

 So the Ubuntu Wiki BtrFS entry advises against using subvol
 set-default because it boots its kernel using root=subvol=@ and home
 as subvol=@home, and these two subvols are only present under the
 subvol with ID 5. But isn't it just possible to move i.e. reparent a
 subvol so I can move these two under another subvol and have that as
 default?

 Make a new subvolume called /root and just mount subvol=root

Sorry if my question wasn't clear: I wanted to know how to move a
subvol to appear under another subvol other than its original parent.
Turns out that sudo mv @ @home target/ is quite sufficient. If so why
would the Ubuntu wiki require that set-default not be used? Just @
@home need to be moved to the new place, no?

 Note that you can't mount subvols recursively in one mount AFAIK.

I'm not sure what you mean. I have a few subvols in my external HDD
which is entirely formatted as BtrFS and if I just mount the external
HDD /dev/sdc1 I am able to access all the subvols' contents as well.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving contents from one subvol to another

On Sun, Nov 30, 2014 at 9:23 AM, Shriramana Sharma samj...@gmail.com wrote:


 Why should noCoW affect cp --reflink anyhow? I just created a 500 MiB
 file from /dev/urandom under a chattr +C-ed dir, and copied to another
 subvol using cp --reflink, and fi df still shows 500 MiB, not 1 GiB.

Looks like I might have spoken too soon (because I've read that some
changes aren't visible until the next FS commit) so right now it
actually says 1 GiB used, which I can't grok because why should a
nocow file be physically copied (to new blocks) just because it's
nocow? Is it because it is possible that the two copies are
overwritten separately at the same time?

But still, it seems to me that mv should make it so that the nocow
attr is temporarily (atomically?) suspended/ignored just for the
duration of the relocation, since there aren't going to be any two
copies to be overwritten at the same time.

Comments?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Change total in btrfs filesystem df output to alloc

Attached patch.

On Sun, Nov 30, 2014 at 9:30 AM, Shriramana Sharma samj...@gmail.com wrote:
 On Sun, Aug 31, 2014 at 7:25 AM, Shriramana Sharma samj...@gmail.com wrote:
 Hello. There seem to be lots of questions in various forums re the
 output of btrfs fi df -- especially w.r.t. the usage of the word
 total. For example see https://community.oracle.com/thread/2459838

 I feel it would make the intent clearer if total were changed to
 alloc or allocated (if the short form is felt unclear). It would
 also help people understand the output of regular df on a btrfs system
 since one can understand easier that pre-allocated space would count
 as used space as it is not free!

 Where should I report a bug to get this fixed? Thanks.

 --
 Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा



-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
From 3d386053105ef7c2dba3643530dffe3ecd4dcf49 Mon Sep 17 00:00:00 2001
From: Shriramana Sharma samj...@gmail.com
Date: Sun, 30 Nov 2014 19:00:38 +0530
Subject: [PATCH] df: change total to alloc

---
 cmds-filesystem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index cd6b3c6..05f6235 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -233,7 +233,7 @@ static void print_df(struct btrfs_ioctl_space_args *sargs, unsigned unit_mode)
 	struct btrfs_ioctl_space_info *sp = sargs-spaces;
 
 	for (i = 0; i  sargs-total_spaces; i++, sp++) {
-		printf(%s, %s: total=%s, used=%s\n,
+		printf(%s, %s: alloc=%s, used=%s\n,
 			group_type_str(sp-flags),
 			group_profile_str(sp-flags),
 			pretty_size_mode(sp-total_bytes, unit_mode),
-- 
2.1.3

Re: root subvol id is 0 or 5?

On Sun, Nov 30, 2014 at 5:29 PM, Hugo Mills h...@carfax.org.uk wrote:

In the data structures on disk, it's 5. The kernel aliases 0 to
 mean subvolid 5.

So why 5 and not just 0 which seems a logical choice? On top of this,
one needs to alias 0 to 5!

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: root subvol id is 0 or 5?

On Sun, Nov 30, 2014 at 7:08 PM, Shriramana Sharma samj...@gmail.com wrote:

 So why 5 and not just 0 which seems a logical choice? On top of this,
 one needs to alias 0 to 5!

Attached patch clarifying this in the documentation. (Should have done
this with the previous mail. Sorry for multiple mails.)

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
From 54387ff2155423d990b5a9aca95315fe6e649303 Mon Sep 17 00:00:00 2001
From: Shriramana Sharma samj...@gmail.com
Date: Sun, 30 Nov 2014 19:11:39 +0530
Subject: [PATCH 2/2] btrfs subvolume doc clarifications

---
 Documentation/btrfs-subvolume.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/btrfs-subvolume.txt b/Documentation/btrfs-subvolume.txt
index 1360aba..34abdef 100644
--- a/Documentation/btrfs-subvolume.txt
+++ b/Documentation/btrfs-subvolume.txt
@@ -31,7 +31,7 @@ When `mount`(8) using 'subvol' or 'subvolid' mount option, one can access
 files/directories/subvolumes inside it, but nothing in parent subvolumes.
 
 Also every btrfs filesystem has a default subvolume as its initially top-level
-subvolume, whose subvolume id is 5(FS_TREE).
+subvolume, whose subvolume id is 5. (0 is also acceptable as an alias.)
 
 A btrfs snapshot is much like a subvolume, but shares its data(and metadata)
 with other subvolume/snapshot. Due to the capabilities of COW, modifications
@@ -166,7 +166,7 @@ sleep N seconds between checks (default: 1)
 
 EXIT STATUS
 ---
-*btrfs subvolume* returns a zero exit status if it succeeds. Non zero is
+*btrfs subvolume* returns a zero exit status if it succeeds. A non-zero value is
 returned in case of failure.
 
 AVAILABILITY
-- 
2.1.3

Considerations in snapshotting and send/receive of nocow files?

Given that snapshotting effectively reduces the usefulness of nocow, I
suppose the preferable model to snapshotting and send/receiving such
files would be different than other files.

Should nocow files (for me only VBox images) preferably be:

1) under a separate subvolume?

2) said subvol snapshotted less often?

3) sent/received any differently?

Thanks.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moving contents from one subvol to another

Hello. I am now taking the first steps to making my backup external
HDD in BtrFS. From
http://askubuntu.com/questions/119014/btrfs-subvolumes-vs-folders I
understand that the only difference between subvolumes and ordinary
folders is that the former can be snapshotted and independently
mounted.

But I have a question. I have two subvols test1, test2.

$ cd test1
$ dd if=/dev/urandom of=file bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 36.2291 s, 14.5 MB/s
$ time mv file ../test2/
real0m2.061s
user0m0.013s
sys 0m0.459s
$ time { cp --reflink ../test2/file .  rm ../test2/file ; }
real0m0.677s
user0m0.022s
sys 0m0.086s
$ mkdir foo
$ time mv file foo/
real0m0.096s
user0m0.008s
sys 0m0.013s

It seems that mv is not CoW aware and hence is not able to create
reflinks so it is actually processing the entire file because it
thinks test2 is a different device/filesystem/partition or such. Is
this understanding correct?

So doing cp --reflink with rm is much faster. But it is still slower
than doing mv within the same subvol. Is it because of the
housekeeping with updating the metadata of the two subvols?

Methinks --reflink option should be added to mv for the above usecase.
Do people think this is useful? Why or why not?

My concern is that if somebody wants to consolidate two subvols into
one, though really only the metadata needs to be processed using
ordinary mv isn't aware of this and using cp --reflink with rm is
unnecessarily complicated, especially if it will involve multiple
files.

And it's not clear to me what it would entail to cp --reflink + rm an
entire directory tree because IIUC I'd have to handle each file
separately. Perhaps something (unnecessarily convoluted) like:

find . | while read f
do
[ -d $f ]  mkdir target/$f  touch target/$f -r $f
[ -f $f ]  cp -a --reflink $f target/  rm $f
done

Again, what would happen to files which are not regular directories or files?

And why isn't --reflink given a single letter alias for cp?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving contents from one subvol to another

On Sat, Nov 29, 2014 at 7:58 PM, Hugo Mills h...@carfax.org.uk wrote:
The latest version of mv should be able to use CoW copies to make
 it more efficient. It has a --reflink option, the same as cp. Note
 that you can't make reflinks crossing a mount boundary, but you can do
 so crossing a subvolume boundary (as you're doing here).

Hi thanks for this. I suppose you are referring to the commit:

http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b47231be6813e6cb5305266e391b4bb745f27f13

From http://git.savannah.gnu.org/cgit/coreutils.git/log/?qt=grepq=mv%3A,
http://git.savannah.gnu.org/cgit/coreutils.git/plain/NEWS?id=b47231be6813e6cb5305266e391b4bb745f27f13
and finally 
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mv.c?id=b47231be6813e6cb5305266e391b4bb745f27f13
it doesn't seem as if there was any earlier commit actually adding a
--reflink option so it seems the improvement is in-built.

That's nice to know!

Any idea when the next coreutils point release with this will be out?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Moving an entire subvol?

So the Ubuntu Wiki BtrFS entry advises against using subvol
set-default because it boots its kernel using root=subvol=@ and home
as subvol=@home, and these two subvols are only present under the
subvol with ID 5. But isn't it just possible to move i.e. reparent a
subvol so I can move these two under another subvol and have that as
default?

Possibly this is a hypothetical question as I'm not sure whether it
would be actually practically required but looking at the specific
Ubuntu advice on this I thought I should ask.

I'm also not sure what openSUSE (or other distros) do about this... Do
they mount root using subvolid, or subvol name or such?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

root subvol id is 0 or 5?

I am confused with this: should I call it the root subvol or
top-level subvol or default subvol or doesn't it matter? Are all
subvols equal, or some are more equal than others [hark to Orwell's
Animal Farm ;-)]?

And more importantly, is the ID of the root subvol 0 or 5?

The Oracle guide
(https://docs.oracle.com/cd/E37670_01/E37355/html/ol_use_case3_btrfs.html)
seems to say it's 0 :

By default, the operating system mounts the parent btrfs volume,
which has an ID of 0

but the BtrFS wiki (and btrfs subvol manpage) reads 5:

every btrfs filesystem has a default subvolume as its initially
top-level subvolume, whose subvolume id is 5(FS_TREE).

as also the Ubuntu Wiki:

The default subvolume to mount is always the top of the btrfs tree
(subvolid=5).

Now this Oracle page
http://www.oracle.com/technetwork/articles/servers-storage-admin/advanced-btrfs-1734952.html
says:

The only clean way to destroy the default subvolume is to rerun the
mkfs.btrfs command, which would destroy existing data.

So from what I've (confusedly) understood so far, 0 refers to the
superstructure (or whatchamacallit) of the entire BtrFS-based contents
of the device(s) and hence cannot be deleted but only reset by a
mkfs.btrfs, but 5 is only the default subvol (mounted when the FS as a
whole is mounted without subvol spec) provided by mkfs.btrfs, and
subvol set-default can have another subvol mounted as default instead,
after which 5 can actually be deleted?

[confused]...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Possible to undo subvol delete?

IIUC with BtrFS while it is possible to easily undelete a file or
ordinary directory if a snapshot of the containing subvol exists, it
seems that it's not elementary to undelete a subvol itself, because
all subvols are under the root-level subvol (id 0 or 5, see my other
q) but even snapshotting the root subvol will not snapshot any subvols
under it.

So is there any way to undo a subvol delete?

[If no, then ordinary users should probably prefer regular directories
to subvols.]

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Experimental tag in FAQ?

https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F still
reads experimental whereas the warning has been removed in the tools
recently IIUC. The FAQ item to be updated, no?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
N�r��yb�X��ǧv�^�)޺{.n�+{�n�߲)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

ToS page does not exist?

I am asked to read the ToS before signing up on the wiki:

Make sure that you first read the Terms of Service before requesting an account.

... but the link is red and the page does not exist.

For signing up I'm going to say I've agreed to the ToS anyhow, but
still either there should be a ToS page or this requirement should not
be there...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Moving contents from one subvol to another

On Sat, Nov 29, 2014 at 10:37 PM, Robert White rwh...@pobox.com wrote:

One thing to keep in mind is that mv, when crossing any of these boundaries
degenerates to a copy-and-remove operation and _none_ of the source files
will be removed until _all_ of the files have been copied. If any of the
copy operations fail the removes will not take place at all. It would only
take a couple large NOCOW files to put you over a limit somewhere.

Hmm... So you're saying like because the copy routine that mv calls
will see the nocow attribute (and it doesn't know it's being called as
part of a move operation) and so do a full copy rather than reflink?

Correct me if I'm wrong but it seems that mv should actually ignore
the nocow attribute as far as moving it to a new location is
concerned, no, because I'm moving, not copying? Of course it should
retain the attribute of the original files *after* the move is done.

Why should noCoW affect cp --reflink anyhow? I just created a 500 MiB
file from /dev/urandom under a chattr +C-ed dir, and copied to another
subvol using cp --reflink, and fi df still shows 500 MiB, not 1 GiB.

If you are consolidating sub-volumes (as per the original question) on a
nearly full drive you may want to do it all long-hand with a script moving
various chunks or something instead of just trying a move/copy of cp
--reflinks /vol1/* /vol2/ (same for mv when you get that --reflinks
revision).

As I said, there doesn't actually seem to be a --reflink command line option.

Re: Change total in btrfs filesystem df output to alloc