Btrfs

[GreyGeek]

Before my system got hosed buy the ubuntu update, I installed the BTRFS tools package. When I tried to run it a message came up that said Sorry your system is incomptable or something like that.

As it so happened my Crystal Ball just happened to break earlier today!

There is no advice we can offer you based on the information you gave us. With every first post of or in a thread you need to include the make and model of your hardware and the version of Linux you have installed, along with any non-repository changes you made. You can't expect the volunteers who help you to remember your specific details. Also include screen captures, if possible, if displayed messages, or consult the various logs in /var/logs that can be accessed by Ksystemlog, dmesg or some editor. The dpkg.log will give you the install msgs made during a package install.

You didn't say what update, or which btrfs tools package you installed and where you got it from. I used Btrfs-tools and it worked fine. I upgraded to btrfs-progs, from the PPA named btrfs-progs posted by Glenn Washburn, and it works faultlessly as well.

[steve7233]

Before my system got hosed buy the ubuntu update, I installed the BTRFS tools package. When I tried to run it a message came up that said Sorry your system is incomptable or something like that.

[jglen490]

Thanks, oshunluvr! I appreciate the input, and I get what you're pointing out. That's definitely a useful enterprise level feature, and it's similar to what was being used on Linux servers at my previous job. Nonetheless, it's a needless complexity with the system I currently have; or at least needlessly complex to go to right now with my very stable, and small, configuration. It might be worthwhile to consider when the next LTS comes out.

As you said, stay tuned!

[oshunluvr]

jglen490, I mostly agree with your assessment. If you're comfortable with your current file system abilities and don't have the need to multi-boot or care about free space distribution you won't use many of the benefits of btrfs.

The one possible benefit I didn't mention that both Grey Geek and myself rely heavily on is the capability to "roll back" to a snapshot. Briefly, a snapshot of a subvolume can functionally replace it's source subvolume. As an example, if your install resides in a btrfs subvolume and you're about to attempt something you might consider even marginally risky - a major version upgrade to Plasma 5 or even a release upgrade to the next Kubuntu version or even just a video card driver upgrade - you simply make a snapshot of your install subvolume (takes literally less than a second) before doing the task. Once complete, if all is well delete the snapshot. If not, delete the now-damaged source subvolume and boot to the snapshot.

Regardless, if or when you decide to try out btrfs, check back with us.

[GreyGeek]

Full indeed! Even retired there's not enough time to do what one wants to do!

[jglen490]

Thanks for your reply GreyGeek!

I use rsync to back up my /home including the /home/multimedia partition on sdb1. It's painless. While it probably is slower due to saving via USB to an external drive, it is safe and provides a very recoverable solution. I have made use of recovery from the full backup from time to time, but again a painless operation.

Again, I deliberately keep my system small and compact. No multiple OS installs, not even to play with, and certainly without the Windows virus. I have learned to stick with the LTS releases and have also learned to wait until .1 release on those. It's very stable and secure and gives me what I need, while being easy to maintain.

With each LTS release I keep my basic partitioning scheme, although before I did the 16.04.1 clean install, I did adjust the / partition by a couple of GBs. The clean install pretty much leaves the /home partitions alone, but I can always recover data files in case of inattention to detail or typing errors! I have plenty of room on the 250GB drive for future expansion of multimedia interests; new pictures from one of our cameras, "oldies" music, info files for other hobbies, and videos.

I don't hate BTRFS, and may make use of it one day, but right now it's unnecessary. Life is full as it is!

[GreyGeek]

...

With that, converting to BTRFS makes no sense at this point with my small system, which does not include multiple users or multiple OS implementations, and which is already being backed up to off-system drives using a rotating media strategy. ...

If you are just backing up your home account data only, and not the entire system, Btrfs may be overkill. Drag & Drop to another mounted device via Dolphin is easy as long as your data doesn't include links to sockets or root files and config files, etc. so is using tar scripts.

For backing up the entire system Cloning tools or ghost imaging is necessary. However, the data in my home account alone is 78Gb and includes links to sound devices (Orbit2010 running with WINE) so a D&D via Dolphin onto another mechanical HD can take 20-30 minutes or more. A Btrfs ro snapshot of both my @ and @home subvolumes takes just a couple seconds. The Btrfs send & receive to a temporarily mounted HD, while taking 20 min each, works in the background while I use my system. It's been a decade since I've used tar scripts or cloning tools but if memory serves me correctly one cannot use their system while using them, so as to "freeze" the state of your system.

Restoring @ and/or @home with Btrfs is significantly easier than other methods.

If one had more than 200-300Gb of data Btrfs would significantly outperform other file systems and backup AND restoration methods.

As far as RAID is concerned I've been using Btrfs for 36 months and RAID1 on two 750 Gb HDs for 6 months. Performance and snapshotting has been flawless. I have never needed to restore from a snapshot ... yet.

I cannot detect any difference in performance or speed between my previous single HD installation and my current two HD RAID1 setup.


Sent from my iPhone using Tapatalk

[jglen490]

Great info! I appreciate the input and the discussions.

While this discussion started I did some research on BTRFS and especially Copy On Write (COW). Were I to be engineering an enterprise level or a business system, BTRFS would be a definite consideration, among other things. COW is not the only consideration for BTRFS, but it seems to be important; Redirect On Write (ROW) is another. From what I've read, COW adds some processing intensity in that for any write there are three I/O activities, and that changes recorded when writing to an existing file are done so in block operations - not file. So the changed data is written in a nearby block and has a reference/pointer to the actual file. That block write can provide the basis of a sort of incremental backup, but is entirely dependent on the existence of the related file. Which brings up the subject of implementing some RAID level. To be effective there needs to be redundancy of storage hardware. The blocks of changes are no good if a hardware problem results in a single redundant drive saying adios - based on some low level of RAID. Higher levels of RAID will make use of additional storage hardware.

Recovery still requires some backup strategy other than incremental.

With that, converting to BTRFS makes no sense at this point with my small system, which does not include multiple users or multiple OS implementations, and which is already being backed up to off-system drives using a rotating media strategy. Maybe the next LTS upgrade, but for now BTRFS is nice but not necessary.

Thank you for the input!

[oshunluvr]

My understanding (I do not use UEFI) is you need a separate EFI partition and then you can boot using UEFI.

The reference Qqmike links to is the section regarding "Partitionless Btrfs disk" which means the entire disk is used without benefit of a partition table. AFAIK, you can't boot to this configuration with GRUB either. My server's data drives are all partitionless, but they are not boot devices.

It's no different than booting to a GPT disk using GRUB - you need a EF02 (grub boot partition) for GRUB to install to. The current practice for this configuration (I do use this) is when partitioning using GPT, set the parameters using gdisk to "expert", unset the parameter that forces all partitions to a 2048 bite boundary alignment, partition the beginning of the disk (up to but not including byte 2048) as an EF02 type partition, then partition as normal. Then you can install GRUB to the GPT disk.

Qqmike is the expert on EFI booting, but I think it's not a whole lot different than the above.

[Qqmike]

One source, so far:

Cannot use [URL="https://wiki.archlinux.org/index.php/UEFI"]UEFI[/URL] to boot.

https://wiki.archlinux.org/index.php/Btrfs

[Qqmike]

UEFI and btrfs?

After 10 minutes of intense searching, I get the sense that this could take some time. Not finding anything (yet) at rodsbooks.com (Rod Smith), but it may be there (UEFI and btrfs). Nor at Arch (but it may be there, too). This hints at it:

https://bbs.archlinux.org/viewtopic.php?id=151589

(and concludes you'd need a separate ESP partition)

[Qqmike]

Trying to think through this ... So, if using UEFI/GPT, I wonder how this works with btrfs. Trying to think through this, where UEFI will look for an ESP (EFI System Partition), marked as such, and containing the bootloaders, and so on.

[oshunluvr]

So, to the OP, Why you might want to use btrfs:

Subvolumes:

No partitioning: You no longer need to partition or you can use a single partition in place of many. I currently have 4 installs and respective /homes all on a single btrfs file system contained within subvolumes. The immediate benefit to this is all free space is available to any of the subvolumes since they all reside on the same file system.
Backups: Subvolumes can be sent from one file system to another in their entirety.

Scale-ability using multiple devices:

Drives or partitions can be added or subtracted from a file system to expand or retract space as needed.
RAID or Not-RAID (JBOD) can be configured or re-configured on multiple devices simply and easily.

The order of importance of these factors will depend on your preferences and needs.

A real-world use case might be if you had a single small hard drive but wanted to multi-boot several Linux installs. Using btrfs, you would not have to guess how much space to partition for each install and would never have to re-size a partition. Just install them all to a single file system using subvolumes and share the space.

Your current configuration,

/dev/sda1        12G     6.8G  4.5G    61% /
/dev/sda2        59G     24G   33G     43% /home
/dev/sdb1        230G    26G   192G    12% /home/multimedia

you could combine into a single file system using both drives. Easiest case, you can create a single file system with your current partitions as is without re-partitioning. You would have a single file system of 301G with 230G available. By using subvolumes, you would still have segregation of / and /home and /home/multimedia if you choose to or you could combine /home and /home/multimedia - my assumption is /home/multimedia exists because there's not enough room on sda to hold your videos and music, etc. All the 230G available space could be used by any of the subvolumes.

Of course, you could re-partition, combining sda1 and sda2 into a single partition of 71G and then match it to a new 71G partition on sdb and use RAID0 (142G) for speed or RAID1 (71G) for redundancy and use the remaining space for backup storage.

Here's the amazing part: With the sole exception of actually re-partitioning your hard drives, you can do everything I listed above while still using your computer - not even a reboot needed.

[vinnywright]

btrfs allso has it's own capabilities ,,,,,, but I know little about that ,,,, @oshunluvr dose however , and will chime in on this one soon I'm sure ...

VINNY

OOPS this was a typo it was supposed to read

btrfs allso has it's own RAID capabilities ,,,,,, but I know little about that ,,,, @oshunluvr dose however , and will chime in on this one soon I'm sure ...

and GG has touched on it some as well ...

VINNY

[GreyGeek]

.... swap is to be considered "emergency" memory rather than "extended" memory, just that you don't lose unsaved work if you ran out of ram)...although this depends on the system's "eagerness" to swap (the configured vm.swappiness value [sysctl vm.swappiness]).....

That was how Bill Ball explained it to me in his now antiquated book Learn Linux in 24 Hours back in May of 1998. (Amazon has the date wrong by a year) It had RH 5.0 on a CD in back of that paperback.

IIRC (a BIG if), fallocate and mkswap were used to create a swap file (not partition) and swapon activated it. When I was running RH5 on my old Sony VAIO desktop, a PCV-90 with a 166MHz processor, 16MB RAM and a 2.1GB HD, I created a 32 Mb swap file (twice RAM because that's what Ball said was needed). When the graphical installers on LiveCDs came into common use they all had swap partition options instead, and that's when swap became a partition for me. I remember the swap file being used on RH5 and SuSE 5.3 but since the advent of GB RAM in the laptops I bought I can't recall a single instance of the swap partition being used. I don't use hibernate or suspend so sometime around Kubuntu 12 I stopped using swap partitions.