On Tue, 18 Nov 2014 09:02:47 -0500 Anton Aylward wrote:

* the ROOT FS is implicit, not a subvolume * I had subvolumes for /home, /usr, /var, /tmp and /.snapshots

Do you see any pro/cons in having ROOT FS as subvolume in regard to ability to have snapshots? (My current system has root as subvolume.) I'm also not sure if one can trick installer to do it... Sincerely, Gour -- Abandoning all attachment to the results of his activities, ever satisfied and independent, he performs no fruitive action, although engaged in all kinds of undertakings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 22 Nov 2014 09:23:22 -0500 Anton Aylward wrote:

If the ROOT FS is the root then there's no sense it it also being a subvolume

Well, the whole setup is cleaner and allows one to e.g. mount one's root to some other place, but I was not aware if there is some gotcha in regard to snapshots.

A subvolume of what?

Of btrfs filesystem. Sincerely, Gour -- The intricacies of action are very hard to understand. Therefore one should know properly what action is, what forbidden action is, and what inaction is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Отправлено с iPhone

22 нояб. 2014 г., в 16:15, Gour написал(а):

On Tue, 18 Nov 2014 09:02:47 -0500 Anton Aylward wrote:

...

* the ROOT FS is implicit, not a subvolume * I had subvolumes for /home, /usr, /var, /tmp and /.snapshots

Do you see any pro/cons in having ROOT FS as subvolume in regard to ability to have snapshots? (My current system has root as subvolume.)

I think this the only setup that makes sense in the long run. I do not know if yast supports it though.

I'm also not sure if one can trick installer to do it...

Sincerely, Gour

-- Abandoning all attachment to the results of his activities, ever satisfied and independent, he performs no fruitive action, although engaged in all kinds of undertakings.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/22/2014 09:38 AM, arvidjaar@gmail.com wrote:

I think this the only setup that makes sense in the long run. I do not know if yast supports it though.

Please explain why you feel it is the only setup that makes sense. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/23/2014 01:31 AM, Andrei Borzenkov wrote:

В Sat, 22 Nov 2014 13:34:16 -0500 Anton Aylward пишет:

...

On 11/22/2014 09:38 AM, arvidjaar@gmail.com wrote:

...

I think this the only setup that makes sense in the long run. I do not know if yast supports it though.

Please explain why you feel it is the only setup that makes sense.

You install new updates and create snapshot before it. Your primary filesystem is in btrfs root and snapshot goes in some subvolume (/.snapshot/backup or anything). You reboot and find that your system does not boot or is not usable. What are your options to go back to working backup?

That's an interesting strawman argument but I don't see it as being realistic or common. And it has nothing whatsoever to do with root as its own subvolume.

1. Copy files from backup snapshot back into root.

It is time consuming, defeats space saving by inflating root and may not be that trivial if directory structure changed.

You seem confused as to the purpose of a snapshot and and confused as to why you should want to reboot after a zypper update. The only time you need to update following a 'update' is of you have replaced or rebuilt the kernel. That is a special case.

2. Mount backup snapshot as root.

So we are exactly in the situation we discuss. We end up with root on subvolume without explicit support from system management tools.

That is not so. There is a mistake in your thinking. Sometimes I get a DUH reaction reading this list and then I realise that not everyone has had the opportunity to be exposed to "Big Iron administrative practices. Snapshoting of the 'before' state when applying changes date back to Big Iron. Snapshots are about being able to roll back updates. They are not backups. We have snapshotting on BtrFS but not on, for example, ReiserFS, because of the COW mechanism if you walk, for example, the /etc tree and the /.snapshot/<number>/snapshot/etc/ tree side by side you will see that for each file they appear to be hardlinked. Actually the snapshot version ow COWed. If it really were a backup then it would be a copy, and making a full copy of the file system for every snapshot will rapidly consume your disk. The state info is bad enough. The purpose of a snapshot is so you can roll back the change(s) resulting from a zypper update. Or possibly, of you have regular by the clock snapshotting enabled, from changes you make by had to the configuration.. let me repeat: A SNAPSHOT IS NOT A BACKUP If you have badly screwed what is in /etc and rendered your system unbootable because of that that mounting a snapshot is not a fix.

3. Set default volume to backup snapshot

Probably just as unsupported as 2; also it raises hairy questions like "what / now refers to, like in /.snapshot".

If your root is on subvolume from the very beginning and all tools are known to support it, fallback is trivial. You are on /@/root-current, you create /@/root-backup; if boot from /@/root-current fails, just point to /@/root-backup and continue to work.

That is completely unjustified and not logical. Firstly in recovery mode there is no need for the root of the file system you are 'mending' to be a subvolume. As I've said before, the 'mending' from recovery of an unbootable systems is a well established procedure and works with any file system. It works, I know from my own experience, with BtrFS without the need for any subvolume trickery. Having booted from the recovery CD/DVD of your choice you can mount the hard disk RootFS at /mnt. You can do this with ANY file system, ext[234], ReiserFS, XFS or BtrFS. All the tools available on your recovery system are still available. If it is a screwed system config that is the reason your system is unbootable then the snapshots look just like a subdirectory and you'll have to fire which one has the prior actual copy. My experience with 'unbootable' has more to do with what's in /boot. Fixing that is quite another matter. It also is independent of the file system being used. All in all you have not presented an argument why a BtrFS has to be a subvolume of itself. The arguments you give are not about 'necessity; what you are trying to achieve with these 'mounts' can be done without the need for subvolumes. Snapshots with BtrFS are an emergent property of the COW mechanism. They are not copies in the conventional sense. Their purpose is for rolling back changes, not for recovery from catastrophic disaster. If you are using the COW mechanism as a substitute for proper backups -- as seems to be the case with the scenarios you describe -- then you are mistaken and going to complicate your life if you do have a disaster that necessitates recovery. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/23/2014 10:53 AM, Gour wrote:

On Sun, 23 Nov 2014 10:23:35 -0500 Anton Aylward wrote:

...

That's an interesting strawman argument but I don't see it as being realistic or common.

I suggest you to visit #btrfs (Freenode) and/or some btrfs mailing lists to expand your vision a bit. ;)

You mistake my meaning and intent. Which was that this has anything to do with the necessity of a) boot failures being specific to BtrFS systems b) the options available for "boot debugging" that are applicable to other file systems are somehow inapplicable to BtrFS There's still been noting state that necessitates having the root of a BtrFS being a subvolume of itself. Those arguments too are all strawmen, Please do not construe this to mean that there are not ways to render a system unbootable, for various meanings of 'unbootable', nor that those ways can be carried out on a system with a BrtrFS root file system. BTDT. Nor does it mean that earlier versions of the BtrFS were unstable enough to cause the systems to become unbootable for reasons that were specific to the root BtrFS. Neither does that mean that even mature file systems do not have fringe conditions, some discovered, some yet to be discovered, that can make them unstable. The reality is that BtrFS is the youngest of the 'popular' file systems because of its association with SSD and has been, like systemd, like KDE4, pushed out aggressively even while immature, and has garnered q lot of criticism when like Kde4 and systemd, its early instances met with problems and failures. Such is the nature of the FSS development model. I've been using BtrFS without BtrFs specific boot problems since late opensuse 12.1. Yes, I've had kernel updates that have gone wrong, but the 'have gone wrong' was confined to /boot which is a ext2FS. The technique I described of using the recovery disk to mount a BtrFS rootFS on the RAMFS /mnt, then mount the hard disk partition /boot on /mnt/boot, then do the /sys, /dev, /proc trickery and chroot to /mnt and then mkinitrd all works. It worked before I started using BtrFS and it works now on a BtrFS without a subvolume of itself. Hypothesising a elaborate configuration specifically to 'show' that a subvolume-of-itself is needed is an unrealistic strawman. I'm not sure how I would classify failing to recognise that snapshots are based around COW rather than real copies. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/23/2014 12:05 PM, Gour wrote:

Iow, the problem is some bug in Suse's grub-mkconfig, since on Debian I get something like:

No, its not a problem. The Debian way, I gather, is to have that /@/ The openSuse way is not to. As far as I can see the problem is that rather than accept that each distribution has its own way of doing things you are, as you say

I want is to have *identical* setup to which I'm accustomed

That is you want to make the openSuse look like a Debian system. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Nov 23, 2014 at 6:23 PM, Anton Aylward wrote:

That's an interesting strawman argument

I do not argue with anything. You asked me to explain and I explained.

Firstly in recovery mode there is no need for the root of the file system you are 'mending' to be a subvolume. As I've said before, the 'mending' from recovery of an unbootable systems is a well established procedure and works with any file system. It works, I know from my own experience, with BtrFS without the need for any subvolume trickery.

Having booted from the recovery CD/DVD of your choice you can mount the hard disk RootFS at /mnt. You can do this with ANY file system, ext[234], ReiserFS, XFS or BtrFS.

All the tools available on your recovery system are still available.

Production systems have limited maintenance window when changes can be applied. If anything goes wrong they do not have luxury of spending time to recover - you need system up and running as soon as possible. btrfs opens up possibility of having cheap and space efficient fallback to known good state so you can easily revert changes. Whether you are going to use this possibility or not - is up to you. I think this possibility is very useful and that current implementation in (open)SUSE makes it less convenient to use than it could be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 22 Nov 2014 17:38:38 +0300 arvidjaar@gmail.com wrote:

I think this the only setup that makes sense in the long run. I do not know if yast supports it though.

I did rename the default subvolumes and created snapshot of rootfs in order to move it from top-level into subvolume (e.g. '@'), but have problem how to teach Yast/Grub to generate proper paths, iow. how to use /@/boot/... instead of /boot/... since manually editing during the boot time works? Any hint? Sincerely, Gour -- Whatever action a great man performs, common men follow. And whatever standards he sets by exemplary acts, all the world pursues. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sat, 22 Nov 2014 21:29:56 +0100 Gour пишет:

On Sat, 22 Nov 2014 17:38:38 +0300 arvidjaar@gmail.com wrote:

...

I think this the only setup that makes sense in the long run. I do not know if yast supports it though.

I did rename the default subvolumes and created snapshot of rootfs in order to move it from top-level into subvolume (e.g. '@'), but have problem how to teach Yast/Grub to generate proper paths, iow. how to use

/@/boot/... instead of /boot/... since manually editing during the boot time works?

Any hint?

Could you remind which openSUSE version you run? Could you be more specific where it fails? There are three places that need adjustment 1. reference to /boot/grub2 in first stage grub binary. If /boot/grub2 was on the same subvolume that was moved (and is now /@/boot/grub2) you need to rerun grub2-install so it picks up new path. 2. Paths to kernels in grub.cfg. They should be updated after rerunning grub2-mkconfig. If not, it is a bug and I would be interested in more information. 3. kernel command line options, specifically subvol=.... Here I'm, not sure. There code to do it is there, but I do not know whether it works. So what exactly does not work in your case? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 23 Nov 2014 09:39:56 +0300 Andrei Borzenkov wrote:

Could you remind which openSUSE version you run?

13.2

Could you be more specific where it fails? There are three places that need adjustment

OK. I managed to rename original subvolumes and put root from the top-level into subvolume. Here is my /etc/fstab: UUID=xyz / btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@ 0 0 UUID=xyz /home btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@home 0 0 UUID=xyz /opt btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@opt 0 0 UUID=xyz /srv btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@srv 0 0 UUID=xyz /tmp btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@tmp 0 0 UUID=xyz /usr/local btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@usr_local 0 0 UUID=xyz /var/crash btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@var_crash 0 0 UUID=xyz /var/log btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@var_log 0 0 UUID=xyz /var/opt btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@var_opt 0 0 UUID=xyz /var/spool btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@var_spool 0 0 UUID=xyz /var/tmp btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@var_tmp 0 0 UUID=xyz swap swap defaults 0 0 UUID=xyz /.snapshots btrfs noatime,noatime,autodefrag,compress=lzo,subvol=@snapshots 0 0 However, I have problem with Grub...

1. reference to /boot/grub2 in first stage grub binary. If /boot/grub2 was on the same subvolume that was moved (and is now /@/boot/grub2) you need to rerun grub2-install so it picks up new path.

Here is the result: # grub2-install /dev/sda Installing for i386-pc platform. Installation finished. No error reported. I notice that /boot/grub2(x86_64-efi directory is empty and wonder if it's normal considering that my install is on x86_64 with BIOS/GPT disk?

2. Paths to kernels in grub.cfg. They should be updated after rerunning grub2-mkconfig. If not, it is a bug and I would be interested in more information.

This is buggy and here are the details with my inline comments: [...] set root='hd0,gpt3' # path is set correctly [...] menuentry 'openSUSE' [...] linux /boot/vmlinuz-3.16.6-2-desktop root=UUID=xyz ${extra_cmdline} resume=/dev/disk/by-uuid/xyz splash=silent quiet showopts # the path is missing /@/boot/ as well as rootflags=subvol=@ echo 'Loading initial ramdisk ...' initrd /boot/initrd-3.16.6-2-desktop # same here - wrong path which should be /@/boot/... [...] menuentry 'openSUSE, with Linux 3.16.6-2-desktop (recovery mode)' [...] linux /boot/vmlinuz-3.16.6-2-desktop root=UUID=xyz ${extra_cmdline} showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe rootflags=subvol=@ # it's strange that here there is rootflags?? but the path is still # wrong echo 'Loading initial ramdisk ...' initrd /boot/initrd-3.16.6-2-desktop # again, wrong path insmod gfxmenu loadfont ($root)/boot/grub2/themes/openSUSE/ascii.pf2 loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans10.pf2 loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans12.pf2 loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans-Bold14.pf2 insmod png set theme=($root)/boot/grub2/themes/openSUSE/theme.txt # the above themes-paths are also wrong!!

3. kernel command line options, specifically subvol=.... Here I'm, not sure. There code to do it is there, but I do not know whether it works.

I hope, from the above it's clear what's wrong? Sincerely, Gour -- In this endeavor there is no loss or diminution, and a little advancement on this path can protect one from the most dangerous type of fear. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Nov 23, 2014 at 7:01 PM, Gour wrote:

On Sun, 23 Nov 2014 16:49:43 +0100 Gour wrote:

...

I hope, from the above it's clear what's wrong?

Forgot to wrote, that in order to boot I have to repeat (ad infinitum) the following sequence after Grub stops in th rescue mode:

...

set prefix=(hd0,gpt3)/@/boot/grub2 set root=(hd0,gpt3) insmod normal normal

which gives me opportunity to fix/edit 'linux' & 'initrd' lines after which openSuse-13.2 boots normally.

If it fails to compute correct path it is just expected that it fails everywhere. Could you attach /proc/self/mountinfo as well as output of btrfs subvolume list -a / btrfs subvolume get-default / grub2-mkrelpath / grub2-mkrelpath /boot/grub2 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Nov 24, 2014 at 11:55 AM, Gour wrote:

...

grub2-mkrelpath / # grub2-mkrelpath / /@

...

grub2-mkrelpath /boot/grub2 # grub2-mkrelpath /boot/grub2 /@/boot/grub2

Absolutely fine.

Of course, the above output was produced in booted Suse-13.2 after I performed the:

...

set prefix=(hd0,gpt3)/@/boot/grub2 set root=(hd0,gpt3) insmod normal normal

sequence.

You mean that if you *now* run grub2-mkconfig and/or grub2-install they will produce paths without /@? Could you please attach output of grub2-mkconfig and grub2-install --debug? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Nov 24, 2014 at 12:51 PM, Gour wrote:

On Mon, 24 Nov 2014 12:03:56 +0300 Andrei Borzenkov wrote:

...

You mean that if you *now* run grub2-mkconfig and/or grub2-install they will produce paths without /@?

Yes.

Weird. I'll need to reproduce it, but I'm on business trip this week without access to my system so I'll be able to do it on weekend. Sorry. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Nov 24, 2014 at 2:54 PM, Gour wrote:

On Mon, 24 Nov 2014 13:14:59 +0300 Andrei Borzenkov wrote:

...

Weird. I'll need to reproduce it, but I'm on business trip this week without access to my system so I'll be able to do it on weekend. Sorry.

The crucial thing to solve was to do:

btrfs subvolume set-default id-of-@ /

It should not be necessary. Actually, grub was explicitly changed to not require set-default. Good that you have workaround, but I will look at it.

Then there was no more resuce mode in Grub and I found out that eve Yast/Boot_Loader generates correct linux/initrd lines - not using '@' in path, but it, somehow, works. :-)

I'm afraid it has something to do with suse-specific patches ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Mon, 24 Nov 2014 15:28:35 +0300 Andrei Borzenkov пишет:

On Mon, Nov 24, 2014 at 2:54 PM, Gour wrote:

...

On Mon, 24 Nov 2014 13:14:59 +0300 Andrei Borzenkov wrote:

...

Weird. I'll need to reproduce it, but I'm on business trip this week without access to my system so I'll be able to do it on weekend. Sorry.

The crucial thing to solve was to do:

btrfs subvolume set-default id-of-@ /

It should not be necessary. Actually, grub was explicitly changed to not require set-default. Good that you have workaround, but I will look at it.

...

Then there was no more resuce mode in Grub and I found out that eve Yast/Boot_Loader generates correct linux/initrd lines - not using '@' in path, but it, somehow, works. :-)

I'm afraid it has something to do with suse-specific patches ...

Yes, it is SUSE specific patch to facilitate snapshot-booting. If SUSE_BTRFS_SNAPSHOT_BOOTING is set to true in /etc/default/grub (I think, it is default during new installation), grub2-mkconfig will generate paths relative to SUBVOLUME, not full absolute paths as upstream does. So e.g. for /some/subvol/path/to/file it will produce just /path/to/file. The intended usage is - you have root in top level subvolume. For this case subvolume is empty and paths are correct - you have snapshots in some subvolume(s). To boot from snapshot, you set grub variable btrfs_subvol to the subvolume path. This is supposed to be done automatically by grub scripts. So paths in snapshot remain the same (/boot/vmlinuz) but now point to files in different subvolume. Where it fails, is the case of primary root on subvolume - it never generates those magic variables to point to to it. I remember speaking with mchang and he mentioned that case of having root on separate subvolume was never intended to be supported. Unsetting SUSE_BTRFS_SNAPSHOT_BOOTING (or setting it to false) will revert to upstream behavior. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 23 Nov 2014 11:29:02 -0500 Anton Aylward wrote:

You do not have a separate /boot listed there.

Correct.

I'd be interested in learning why you chose not to have a separate /boot partition.

Because the Linux OS has advanced and there is no longer required to keep separate /boot. Moreover, I use Debian with such setup for more than one year without any problem: UUID=xyz / btrfs defaults,noatime,compress=lzo,autodefrag,subvol=@ 0 0 UUID=xyz /home btrfs defaults,noatime,compress=lzo,autodefrag,subvol=@home 0 0 As you can see, there are not so many subvolumes as created by default by Yast, but it works. Sincerely, Gour -- A person who has given up all desires for sense gratification, who lives free from desires, who has given up all sense of proprietorship and is devoid of false ego — he alone can attain real peace. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 23 Nov 2014 12:26:53 -0500 Anton Aylward wrote:

Some people call this 'belt and braces' engineering :-0

I appreciate your intention to help and just wonder if you maybe like Ada language?

Even so, it doesn't take an errant programmer to come up with a runaway process that can consume all the scape on /tmp.

In my case, it's single-user desktop machine and I'm the only programmer who can fill the /tmp. :-)

I asked why you chose not to have a separate /boot and the answer seems to be "'Cos Debian didn't do it that way".

Wrong! It might be that Debian stable still uses /bot, but I run Linux without /boot for quite some time. Moreover, it's, as pointed out by jjd, even the decision of Suse itself, at least for 13.2. ;)

It makes me wonder why you have chosen to move from Debian to openSuse as you seem intent on rebuilding your openSuse system so that it looks like a Debian system.

There are more things relevant for chosing the distro besides disk layout. Zipper is certainly the one. ;) Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 23 Nov 2014 14:45:06 -0500 Anton Aylward wrote:

I think you have another conceptual problem here. The 'default' is minimal. There is nothing forcing you to take what the default offers.

So, why are you not satisfied with what defaut is offering and which should be safe for majority of users and go to the unsafe path not recommended by the distro creators themselves? :-) Sincerely, Gour -- You have a right to perform your prescribed duty, but you are not entitled to the fruits of action. Never consider yourself the cause of the results of your activities, and never be attached to not doing your duty. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 23/11/2014 20:45, Anton Aylward a écrit :

On 11/23/2014 12:48 PM, Gour wrote:

...

Moreover, it's, as pointed out by jjd, even the decision of Suse itself, at least for 13.2. ;)

I think you have another conceptual problem here. The 'default' is minimal. There is nothing forcing you to take what the default offers.

sure, but it's the best openSUSE gurus can offer... and, by the way if you use several partitions, you have to multiply them by the number of linux distros installed - for me at least two (I nver upgrade in place my main machine) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 23/11/2014 21:05, Anton Aylward a écrit :

That's a specious argument. You know full well that one autoyast script is all that's needed. *NIX has long been about ways to avoid repetitious work1

? let alone remember what partition do what on the systems that do not run now? I already have more than 17 partitions on 4 disk on my main machine :-) by the way we are drifting far from the inital post, on this machine I have no BTRFS file system.... most problem are between the chair and the keyboard, reason why keeping things (reasonably) simple is usefull. that don't mean your config do not fit *your* needs, but I often prefere default configs well known by everybody than special config I will certainly be the only people able to fix occasionnally jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Nov 23, 2014 at 10:57 PM, jdd wrote:

Le 23/11/2014 20:45, Anton Aylward a écrit :

...

On 11/23/2014 12:48 PM, Gour wrote:

...

Moreover, it's, as pointed out by jjd, even the decision of Suse itself, at least for 13.2. ;)

I think you have another conceptual problem here. The 'default' is minimal. There is nothing forcing you to take what the default offers.

sure, but it's the best openSUSE gurus can offer...

and, by the way if you use several partitions, you have to multiply them by the number of linux distros installed - for me at least two (I nver upgrade in place my main machine)

Which is the excellent example of use case I tried to explain - clone system, update, if update is OK - just destroy original system; if update does not look good - simply go back and destroy new clone. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/23/2014 12:48 PM, Gour wrote:

...

...

Even so, it doesn't take an errant programmer to come up with a runaway process that can consume all the scape on /tmp.

In my case, it's single-user desktop machine and I'm the only programmer who can fill the /tmp. :-)

Yes but you run code written by other programmers and we've long ago established that some of the contributions are less than perfect! Then there's the matter of configuration. Dare I say it, but some configurations are less than perfectly applicable to some situations and can cause, lets putt it politely, errant behaviour. HO! A lot of the discussion on this list pertains to that. I said that I assume things that can go wrong will go wrong and things that can't go wrong will also go wrong. This list is a testimony to that! Right now my /tmp is lowly filling up because there are quite a number of applications that create temporary files and don't delete then when they exit. I think the Mozilla suite is among them! I am *sure* that Thunderbird does not clear up the attachments I open. Damn FTP-by-mail! The crontab.daily is supposed to clear out /tmp but it doesn't seem to do a good job. We have large disks these days, so creating a 1G /boot on a 1T drive, the drive costing you around $50, isn't going to hurt. Its a simple precaution, like spending $1 for a CO2/smote alarm battery. There are a lot of simple precautions in life, but I've never understood why people spend s much energy arguing why they shouldn't take them. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 23/11/2014 17:29, Anton Aylward a écrit :

I'd be interested in learning why you chose not to have a separate /boot partition.

default install do not make one jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 23 Nov 2014 11:33:22 -0500 Anton Aylward wrote:

It looks to me like grub2 doesn't know about your /@/ part.

Right.

Since the openSuse YAST installer doesn't know about that I'm not surprised.

Well, Yast is not the only tool to manage one's OS. I believe that e.g. Yast can't create full ISP mail server with virtual domains, using MySQL for handlin domains/accounts/aliases, Dovecot with full SASL auth. etc., but I still like that Yast can help with *many* other tasks.

The reso of the opensuse community seems to have got by without the /@/ - the root at a subvolume of itself, so far.

Well, btrfs & snapshotting are new things in Suse. Those things are not present in Debian (Sid) either, but there, at least, one can configure it manually.

I'm still unclear as to why you are so insistent about begin different.

First of all, I'm in the process of moving from Debian to Suse, and one thing I want is to have *identical* setup to which I'm accustomed for some time already. Moreover, when/if you have need to boot with some rescueOS and you mount your OS, it much nicer to see something like this: $ ls -l /mnt/btrfs/ total 0 drwxr-xr-x 1 root root 210 Lis 18 16:21 @/ drwxr-xr-x 1 root root 20 Tra 23 2014 @home/ than your whole OS populated with files. Sincerely, Gour -- A person is considered still further advanced when he regards honest well-wishers, affectionate benefactors, the neutral, mediators, the envious, friends and enemies, the pious and the sinners all with an equal mind. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/23/2014 11:55 AM, Gour wrote:

Well, btrfs & snapshotting are new things in Suse.

No they are not. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 18 Nov 2014 17:27:08 +0300 Andrei Borzenkov wrote:

Yes, I did it in previous openSUSE releases (not production system though). Downside is that you cannot use YaST partitioner;

I'm thinking about cofiguring one disk and then manually add the 2nd one into mirror. Otoh, I wonder, since it's official decision to use XFS to /home to follow their hint and wait when /home with btrfs will become official practice, possibly with subvolumes. Do you use XFS or what you recommend for /home?

also not sure about yast-bootloader - it will likely not understand that there are multiple disks to install bootloader on. Although editing /etc/default/grub_installdevice manually could work.

Iirc, I had to manually install Grub2 into MBR on Debian as well, so not a big issue. Sincerely, Gour -- A person is said to be elevated in yoga when, having renounced all material desires, he neither acts for sense gratification nor engages in fruitive activities. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On November 19, 2014 3:52:17 PM EST, John Andersen wrote:

On 11/19/2014 12:33 PM, Gour wrote:

...

Otoh, I wonder, since it's official decision to use XFS to /home to follow their hint and wait when /home with btrfs will become official practice, possibly with subvolumes.

That's what I did. I'm not sure why they did it this way, but they have spent more time thinking abut it than I did, so I went with it.

Also I wanted to encrypt home (and another project directory) and Yast didn't offer encryption for Btrfs, even though the documentation said it can be done.

I've encrypted my home dir with ecryptfs over btrfs and have been running that way for a very long time now. This isn't "available" or "supported" by yast or whatever but is fully supported outside that by the kernel, encryptfs-utils, pam-config, etc. -- Later, Darin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On November 19, 2014 4:55:29 PM EST, John Andersen wrote:

On 11/19/2014 1:52 PM, Darin wrote:

...

On November 19, 2014 3:52:17 PM EST, John Andersen

...

...

On 11/19/2014 12:33 PM, Gour wrote:

...

Otoh, I wonder, since it's official decision to use XFS to /home to follow their hint and wait when /home with btrfs will become official practice, possibly with subvolumes.

That's what I did. I'm not sure why they did it this way, but they have spent more time thinking abut it than I did, so I went with it.

Also I wanted to encrypt home (and another project directory) and Yast didn't offer encryption for Btrfs, even though the documentation said it can be done.

I've encrypted my home dir with ecryptfs over btrfs and have been running that way for a very long time now. This isn't "available" or "supported" by yast or whatever but is fully supported outside that by

wrote: the kernel, encryptfs-utils, pam-config, etc.

...

Does Btrfs see that as one big file or what?

No its layered above the file system so any and every file/Dir passes thru the ecryptfs layer and gets encrypted. It's file system agnostic and since its above the FS doesn't require anything special, unlike dmcrypt or the blob encrypted home Dir which is SUSE's default, if you extend the disk or volume.

Does it affect snapshots in any way?

Not that I'm aware of. -- Later, Darin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org