On Saturday 15 November 2014 00:01:47 John Andersen wrote:

On November 14, 2014 11:46:06 PM PST, Stanislav Baiduzhyi wrote:

...

Hi All,

I was little surprised that openSUSE went with Btrfs for / but with XFS for /home. So I have to ask this question: when and why I should *not* use Btrfs for /home?

I've heard/read somewhere that Btrfs handles virtual machines badly, because of huge random access disk file and COW nature of Btrfs, can anyone confirm that?

What other use-cases Btrfs handles badly?

Well, It appears that it does not handle encryption, and people often like to encrypt their home directory.

But it does, the same way XFS and Ext4 are doing it: https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_encryption.3F That was a decision in openSUSE team to disable "encrypt" checkbox if Btrfs is chosen, I don't know why. -- Regards, Stas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-11-15 10:54, Hans Witvliet wrote:

On Sat, 2014-11-15 at 09:17 +0100, Stanislav Baiduzhyi wrote:

Perhaps it depends on previously made choices: If you _did_ choose to use lvm, then you can place /home into a encypted volume. The filesystem will be completely unaware of it. If you just use plain partitions, you are out of luck.

Remember that only a subset of all the btrfs-features are implemented on SuSE. Only those features they know that are reliable enough hit the big audiance. In contrast to "others", suse is offering btrfs already for a

That's irrelevant. LUKS encryption on a partition is placed above the partition and below the fileystem, whatever filesystem. It works even with FAT and NTFS, which certainly have not been designed for it. If you are talking of a feature _internal_ to btrfs that supports encryption /internally/, that's a different feature. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On November 15, 2014 11:01:07 AM EST, Stanislav Baiduzhyi wrote:

On Saturday 15 November 2014 08:20:07 Greg Freemyer wrote:

...

It is a generic issue of performance and scalability, xfs is the most scalable and highest performing Linux fs at present, so it is a natural default for most file systems, especially large busy file systems.

I'm surprised to hear that. I thought about moving /home back to ext4 or to experiment with btrfs because I'm extremely unsatisfied with XFS at the

moment, with the same system setup and use-case as for ext4.

The xfs mailing list is unbelievably responsive to end user questions, especially those that relate to performance tuning. If you are having issues I suggest you go straight to the horse's mouth. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/15/2014 11:14 AM, Stanislav Baiduzhyi wrote:

On Saturday 15 November 2014 08:51:11 Anton Aylward wrote:

...

On 11/15/2014 02:46 AM, Stanislav Baiduzhyi wrote:

...

I've heard/read somewhere that Btrfs handles virtual machines badly, because of huge random access disk file and COW nature of Btrfs, can anyone confirm that?

DUH?

Why not do as I have done - create another partition using another FS type and mount that under /home/<user>/VMs/

What? You mean you are not using LVM and can't create (possibly encrypted) partitions on-demand as the need arises? Can't take snapshots to simplify backups?

Hm, that is really good idea. I do not trust LVM, so I will experiment with mounting subvolume with nodatacow, maybe that will work as I expect...

NOT! I can't see why not to trust LVM. Its got a good heritage before it was imported into Linux. I've been using it for nearly a decade and its never given me any problems. Its at least as reliable as the extN file systems and the ReiserFS. I've not used XFS so I can't comment. I say "NOT!" becuase a subvolume of a BtrFS partition is not really a new partition, its and administrative & management aspects. In many ways it behaves like a subdirectory in that it uses space on the 'parent'. You are NOT, repeats NOT mounting a new piece of storage. The manual page says quite explicitly <quote> A subvolume in btrfs is not like an LVM logical volume, which is quite independent from each other, a btrfs subvolume has its hierarchy and relations between other subvolumes. </quote> -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/18/2014 05:20 AM, Stanislav Baiduzhyi wrote:

On Saturday 15 November 2014 13:37:46 Anton Aylward wrote:

...

NOT!

I can't see why not to trust LVM. Its got a good heritage before it was imported into Linux. I've been using it for nearly a decade and its never given me any problems. Its at least as reliable as the extN file systems and the ReiserFS. I've not used XFS so I can't comment.

I say "NOT!" becuase a subvolume of a BtrFS partition is not really a new partition, its and administrative & management aspects. In many ways it behaves like a subdirectory in that it uses space on the 'parent'. You are NOT, repeats NOT mounting a new piece of storage.

The manual page says quite explicitly

<quote> A subvolume in btrfs is not like an LVM logical volume, which is quite independent from each other, a btrfs subvolume has its hierarchy and relations between other subvolumes. </quote>

I cannot understand your point... Yes subvolume is not LVM, but my goal is to have some files (or all files in subfolder) to have 'nodatacow' by default, it is not a synonym of LVM. I'm not convincing you to abandon LVM, I just don't trust it. Showstoper for me will be if btrfs cannot mount subvolume with 'nodatacow', but my test on VirtualBox guest went fine, so I will try the same on my laptop when I'll be upgrading from 13.1 to 13.2.

Let try that in parts. Can we leave LVM out of it. The BtrFS people only mentioned LVM because, like LVM, BtrFS can be set up to cover many spindles. A subvolume is not a separate container. That means its not a separate partition, it is part of the main FS and -- this is the important part -- share all the characteristics of the main part, the block size etc etc. It is part of the hierarchy, in that it is functionally like a subdirectory. You can set up a relation -- that is a HARD LINK -- between a file in the subvolume and elsewhere on the FS, possibly in another subvolume. You can't do that if the mount is really of a separate container with different characteristics. You would have to use symlinks. LVM is just a way of managing disk space that is very flexible. LVM is not a file system. The result of using LVM is that you can create new partitions -- logical volumes -- dynamically (and resize them) without using the traditional partition tools such as fdisk. One would then have to create a file system on the Logical Volume; this can be ANY file system, ext2/3/4, resiserfs, xfs or even btrfs! The mount just as if it were a partition created with fdisk. Such a volume is mounted in the traditional way but is a separate file system. By contrast a BtrFS subvolume is part of the original file system. If I were to remove the entry for the subvolume from /etc/fstab it would make no difference to the running system. The subvolume would still be there. I know this, I've done it. Similarly you can create a subvolume and not add it to /etc/fstab. I've done that too. As it happens, I manage my complete disk with LVM except for the boot partition. The machine I'm working at now only has the one disk so I'm not making use of LVM's ability to span many spindles, to do mirroring or striping. It is because of these facilities that people draw an analogy with BtrFS, but I think it is unfair. LVM is a disk space management tool that lives _underneath_ the file system. BtrFS is a file system that can extend across many containers. One of my LVM Logical volumes has my ROOT on it. # mount ... /dev/mapper/vgmain-vROOT on / type btrfs (rw,relatime,space_cache) # lvdisplay /dev/mapper/vgmain-vROOT --- Logical volume --- LV Path /dev/vgmain/vROOT LV Name vROOT VG Name vgmain LV UUID 7j4Cuf-GIJ0-5B5L-qPJQ-YB2T-MsRK-9Tj2hP LV Write Access read/write LV Creation host, time linux, 2014-03-26 14:16:11 -0400 LV Status available # open 1 LV Size 20.00 GiB Current LE 5120 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:10 When I installed, that LV was just 10G and the system fit on it! But as time went by I installed more things and had more kernels in /lib so I grew both the LV and then the file system. I had to grow the container - the LV first. LVM is a tool for managing the disk space, quite independently of the file system you choose to implement in any of the containers -- Logical Volumes -- you create. LVM is NOT a file system. You could, and it might possibly be quite optimal in terms of deduplication, to create a single BtrFS that spanned all of the disk, all of the disks on the system. Use fdisk to create a single partition. have all of ROOT, /boot, /home, /srv, /usr, /opt, /local ... All on the one FS. They might be subvolumes, if that makes management such as doing backups easier, but that is optional. The important point is that a subvolume is more like a subdirectory than it is like mounting another FS. If anything it is more like a bind mount. After mounting a subvolume it is the same file system underneath. As far as programs that access anything under that point, it makes no difference whether or not the mount has been done. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/18/2014 02:47 PM, John Andersen wrote:

On 11/18/2014 05:22 AM, Anton Aylward wrote:

...

You can set up a relation -- that is a HARD LINK -- between a file in the subvolume and elsewhere on the FS, possibly in another subvolume.

Are you sure of this?

http://comments.gmane.org/gmane.comp.file-systems.btrfs/7031

That thread is from 2010. It is now the end of 2014 and a lot more work has been done on BtrFS since then. Hardlinks did when I tried it back when I had a btrFS as everything all on the one disk and nothing else and a number of subvolumes. Lined from something under subvolume /home to subvolume /tmp. The 'causes bugs' doesn't make sense. If I had a single FS ext4Fs system I could hard link as in the example above, so why not on BtrFS? It does say in the docs that subvolumes are like directories :-) The last post at your reference says

If btrfs is to support deduplication one day, it has to work across subvolumes - otherwise, it won't be very useful.

I agree with that. Right now we do have tools, I forget the name, which walks a FS and looks for identical files to hardlink so as to reduce space used. Are you saying those tools won't work on BtrFS? I say they do. I say hard links do work. Here's my evidence. Right now I have BtrFS as ROOT and it has zypper snapshotting enabled so I have the following # btrfs subvolume list / ID 269 gen 343531 top level 5 path .snapshots ID 541 gen 341419 top level 269 path .snapshots/1/snapshot ID 542 gen 341419 top level 269 path .snapshots/2/snapshot ID 544 gen 341419 top level 269 path .snapshots/3/snapshot ID 545 gen 341419 top level 269 path .snapshots/4/snapshot ID 546 gen 343373 top level 269 path .snapshots/5/snapshot ID 547 gen 343378 top level 269 path .snapshots/6/snapshot Mainbox:~ # # ls -li /etc/hosts /.snapshots/6/snapshot/etc/hosts 863349 -rw-r--r-- 1 root root 1268 Jun 13 18:37 /etc/hosts 863349 -rw-r--r-- 1 root root 1268 Jun 13 18:37 /.snapshots/6/snapshot/etc/hosts # sum /etc/hosts /.snapshots/6/snapshot/etc/hosts 57395 2 /etc/hosts 57395 2 /.snapshots/6/snapshot/etc/hosts # cksum /etc/hosts /.snapshots/6/snapshot/etc/hosts 1962092743 1268 /etc/hosts 1962092743 1268 /.snapshots/6/snapshot/etc/hosts See, same size, same inode. I believe that constitutes a hard link. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org