BTRFS - Have you tried it?

Cdh · 2010-09-13 02:34:35

falconindy wrote:

<source> is the source of the snapshot. <dest> is where the snapshot is going to reside.

That's what one does but it doesn't tell me HOW things should be done and how thy look like.

falconindy wrote:

# mkdir /mnt/root
# mount /dev/sda2 /mnt/root

I mady my subvolume with the current root system the default one. So I would mount my already mounted root filesystem there?
I think I would mount it with -o subvol= (empty)

falconindy wrote:

# btrfs snapshot /mnt/root/__active /mnt/root/__snapshots/2010-09-12

I still don't get it. /mnt/root/__snapshots/ will be automatically created?

Thanks for your answer anyway. The wiki could need more information for beginners with btrfs...

falconindy · 2010-09-13 10:39:34

If you didn't put your / in a subvolume, you can't snapshot it. My "root" when mounted without a subvol looks like this:

.
├── __active
│   ├── bin
│   ├── boot
│   ├── dev
│   ├── etc
│   ├── home
│   ├── lib
│   ├── media
│   ├── mnt
│   ├── opt
│   ├── proc
│   ├── root
│   ├── sbin
│   ├── srv
│   ├── sys
│   ├── tmp
│   ├── usr
│   └── var
└── __snapshot
    ├── snap_2010-06-19
    └── snap_2010-08-03

Under normal conditions, I'm mounting / with the option 'subvol=__active'. If I want to snapshot it, I mount the actual root of the device and snapshot __active into a new dated subvolume in __snapshots, similar to what I posted before. If I need to roll back, I can just mount one of the old snaps and boot.

extofme · 2010-09-13 18:27:15

Cdh wrote:

falconindy wrote:
# btrfs snapshot /mnt/root/__active /mnt/root/__snapshots/2010-09-12
I still don't get it. /mnt/root/__snapshots/ will be automatically created?
Thanks for your answer anyway. The wiki could need more information for beginners with btrfs...

you will have to create them yourself. if you are using mkinitcpio-btrfs from AUR, the hook expects the folders:

__active
__snapshots

to exist. the hook also expects your "active", or "actual" / (root) to exist WITHIN __active. anything within __snapshots can be selected at boot time; if you choose a snapshot (via the hook prompt), the hook will create a COPY (snapshot) of the snapshot, to __rollback, and boot that instead (to preserve the original snapshot). at this point, you are inside a rollback environment. you may either:

) manually fix whatever is wrong with __active
) manually remove __active, and snapshot __rollback to __active, ("promoting")

right now, there is not a tool to do any of this for you; it must be done manually. the hook only allows you to boot whatever is _already_ in __snapshots. if you did not create an __active subvol, and install INTO that, then you must snapshot / to __active, reboot, and manually rm -rf everything EXCEPT __active and __snapshot. somewhat confusing, but read it again, it'll make sense

@falconidy, i used to have a simple ~10 line bash tool bundled with the hook so people did not have to do this stuff manually; are you using a tool of some sort? if so, and you want, i could add it to the mkinitcpio-btrfs package so others could make use of it until i finish the one i've started (it's based on a bash application template i wrote awhile back, and is very clean/flexible, but anything would work in the interim).

C Anthony

combuster · 2010-09-13 19:18:09

I was testing it with maverick on another partition and there is still a nasty bug with dpkg and fsync with btrfs, installation took 2hrs with alternate install, one hour with initial update (but i canceled it cause i couldn't wait any longer) and dropped the whole thing. I've "measured" performanse with pts and btrfs was multiple times slower than ext4.

EXT4 – R/W : 2474/261 MBps – kernel 2.6.34
BTRFS – R/W : 1485/76 MBps – kernel 2.6.35

These are old results from maverick alpha2 (ext4 performanse was measured under arch), but situation isn't any better now....

arch0r · 2010-09-13 20:53:30

does the btrfs disk compression mode bring any improvements in speed or performance?

extofme · 2010-09-13 22:02:57

combuster wrote:

I was testing it with maverick on another partition and there is still a nasty bug with dpkg and fsync with btrfs, installation took 2hrs with alternate install, one hour with initial update (but i canceled it cause i couldn't wait any longer) and dropped the whole thing. I've "measured" performanse with pts and btrfs was multiple times slower than ext4.
EXT4 – R/W : 2474/261 MBps – kernel 2.6.34
BTRFS – R/W : 1485/76 MBps – kernel 2.6.35
These are old results from maverick alpha2 (ext4 performanse was measured under arch), but situation isn't any better now....

btrfs is not ext4; you haven't noted anything about your hardware, setup, mount options, nor the workload that produced such numbers. additionally, you have tested different kernels, without regard to previous posts linking to a rather severe btrfs regression bug in .35. btrfs is already rather performant; my T43 laptop "feels" the same, but my eee s101 netbook absolutely screams under btrfs (SSD).

btrfs has demonstrated several times already as performing very well, or better, under *most* workloads. fsync() is notorious for being abused, misused, and flat out misunderstood. dpkg is having problems adjusting; there is info about this all over then net, and it isn't really btrfs's problem. i has seen very successful reports on the btrfs list of multidisk arrays already approaching ZFS throughput, somewhat shy of theoretical maximums. i would advise reading further, and trying to understand workloads and why btrfs is different, prior to any final conclusions.

arch0r wrote:

does the btrfs disk compression mode bring any improvements in speed or performance?

yes, if your workload compliments it, and your system can cope with the extra CPU cycles. it can significantly increase read performance of highly compressible files such as text/scripts/etc, but will not even attempt to compress already compressed files like images and videos (IIRC, btrfs will try to compress a small portion of the file, and if it doesn't compress well, the file is skipped). in general, performance is improved due to less overall physical IO, but if your workload doesn't compliment performance will be the same (and still waste CPU) or worse.

additionally, some chips [Intel] support hardware CRC, and this has been reported as a rather sizeable performance boost.

C Anthony

falconindy · 2010-09-14 00:22:18

extofme wrote:

@falconidy, i used to have a simple ~10 line bash tool bundled with the hook so people did not have to do this stuff manually; are you using a tool of some sort? if so, and you want, i could add it to the mkinitcpio-btrfs package so others could make use of it until i finish the one i've started (it's based on a bash application template i wrote awhile back, and is very clean/flexible, but anything would work in the interim).

Nah, I've been doing it manually as I don't do it very frequently. I keep meaning to script it myself but it keeps getting pushed down in my ever increasing stack o' stuff-to-do.

C Anthony

falconindy

Cdh · 2010-09-14 08:35:45

Something I noted:
I copied a 12 GB file from a pretty fast ubuntu laptop to my netbook with the -pf kernel and btrfs. Then I wanted to be sure that the file is ok and did md5sum on it on both laptops.
The ubuntu laptop took MUCH longer than my netbook to do the md5sum...

I meant:
I did btrfs subvolume set-default <id> <path> on my subvolume with the root filesystem. So when I do mount /dev/sda1 /mnt without options then my root filesystem gets mounted there.

extofme · 2010-09-14 17:47:23

falconindy wrote:

extofme wrote:
@falconidy, i used to have a simple ~10 line bash tool bundled with the hook so people did not have to do this stuff manually; are you using a tool of some sort? if so, and you want, i could add it to the mkinitcpio-btrfs package so others could make use of it until i finish the one i've started (it's based on a bash application template i wrote awhile back, and is very clean/flexible, but anything would work in the interim).
Nah, I've been doing it manually as I don't do it very frequently. I keep meaning to script it myself but it keeps getting pushed down in my ever increasing stack o' stuff-to-do.

ugh, tell me about it; i went from sitting fairly well (2mo away from debt free!!!) to the worst financial state of my life in about 18 months... who knew a new family + baby would be so damn expensive :-). i have about 3-4 arch related things i really want to work on, but can't, until i regain my stability.

Cdh wrote:

I meant:
I did btrfs subvolume set-default <id> <path> on my subvolume with the root filesystem. So when I do mount /dev/sda1 /mnt without options then my root filesystem gets mounted there.

ah, the hook in AUR doesn't mess with set-default, it mainly just manipulates the subvol mount option. i have considered using set-default, but it does not do what i expected... i thought that the "." subvol would _always_ be the "true" btrfs root, and set-default would just affect what was mounted when the subvol option was omitted, but that's not the case; after using set-default, the "." becomes whatever you just set.

the problem is, after setting a new default, i don't know how to mount the real btrfs root, _ever again_...

however, i may use this property to support kernel level rollbacks with extlinux bootloader, if possible.

C Anthony

Last edited by extofme (2010-09-14 17:52:07)

Cdh · 2010-09-14 22:02:09

extofme wrote:

i have considered using set-default, but it does not do what i expected... i thought that the "." subvol would _always_ be the "true" btrfs root, and set-default would just affect what was mounted when the subvol option was omitted, but that's not the case; after using set-default, the "." becomes whatever you just set.
the problem is, after setting a new default, i don't know how to mount the real btrfs root, _ever again_...

That should maybe go into the manpage. I didn't know of this either.

Thank you, this clarifies much of the above post for me.

Arch Linux

#26 2010-09-13 02:34:35

Re: BTRFS - Have you tried it?

#27 2010-09-13 10:39:34

Re: BTRFS - Have you tried it?

#28 2010-09-13 18:27:15

Re: BTRFS - Have you tried it?

#29 2010-09-13 19:18:09

Re: BTRFS - Have you tried it?

#30 2010-09-13 20:53:30

Re: BTRFS - Have you tried it?

#31 2010-09-13 22:02:57

Re: BTRFS - Have you tried it?

#32 2010-09-14 00:22:18

Re: BTRFS - Have you tried it?

#33 2010-09-14 08:35:45

Re: BTRFS - Have you tried it?

#34 2010-09-14 17:47:23

Re: BTRFS - Have you tried it?

#35 2010-09-14 22:02:09

Re: BTRFS - Have you tried it?

Board footer