what is the Installed OS size and which version should i choose

[mastablasta]

so if i went brtfs the default could be (on MBR partitioning, no "secure" boot):
/
/swap (2GB at least)

or does it need a separate home.

it seem i really need to read up more on it.

also i am not sure i would need the Neon edition. but you never know. i used to have PPA added for latest Plasma on 12.04 and that worked rather well.

primarily i need something that is stable and needs the least amount of time messing with it. the winXP should be a dead giveaway :-). but seriously, when i was younger i had the time to mess around with PC and OS and settings and such, but i didn't really have a PC, now i have the PC, but no time. the irony. but i many years, when i retire, i will have both. until then, i really appreciate something that works and doesn't need me to trouble shoot it constantly. which is why snapshots would be beneficial, to be able to just revert to previous state until i have time to fix it properly.

i now did a test with 16.04.1 32 bit (i though the DVD i had recorded some time ago was 64bit Mostly it was OK, but i did hit a few strange things particularly in the high CPU usage after install: https://www.kubuntuforums.net/showth...626#post407626

[Snowhog]

I've already started another thread to discuss this realization and a way to prevent this from happening again.

Would you edit this post and provide the link to the thread?

[oshunluvr]

Mines bigger:

[FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]/subvol[/B][/COLOR][COLOR=#000000]$ ll[/COLOR]
total 4
drwxr-xr-x 1 root root 676 Nov 29 09:44 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov 26 02:00 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov 26 02:00 [COLOR=#5454FF][B]@KDEneon[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov 27 02:00 [COLOR=#5454FF][B]@KDEneon_171127[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov 28 02:00 [COLOR=#5454FF][B]@KDEneon_171128[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov 26 18:35 [COLOR=#5454FF][B]@KDEneon_bad[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 268 Nov 29 11:27 [COLOR=#5454FF][B]@KDEneon_good[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Sep  6 16:46 [COLOR=#5454FF][B]@KDEneon_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Nov 26 03:00 [COLOR=#5454FF][B]@KDEneon_home_171126[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Nov 27 03:00 [COLOR=#5454FF][B]@KDEneon_home_171127[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Nov 28 03:00 [COLOR=#5454FF][B]@KDEneon_home_171128[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 196 Jun 13 16:49 [COLOR=#5454FF][B]@KDEneon_new[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  12 Jun 13 16:41 [COLOR=#5454FF][B]@KDEneon_new_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Nov  8 14:59 [COLOR=#5454FF][B]@KDEneon_save[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov  9 14:53 [COLOR=#5454FF][B]@KDEneon_save2[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Nov 26 18:35 [COLOR=#5454FF][B]@KDEneon_save3[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 262 Dec 13  2016 [COLOR=#5454FF][B]@Kubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  32 Dec 22  2016 [COLOR=#5454FF][B]@Kubuntu_16_04_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 282 Jun 27 09:31 [COLOR=#5454FF][B]@Manjaro_free[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  12 Jun 11 08:11 [COLOR=#5454FF][B]@Manjaro_free_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 216 Nov  9 14:06 [COLOR=#5454FF][B]@Manjaro_nonfree[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  12 Jun 10 11:49 [COLOR=#5454FF][B]@Manjaro_nonfree_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 234 Jun 13 17:21 [COLOR=#5454FF][B]@Ubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  12 Jun 13 16:14 [COLOR=#5454FF][B]@Ubuntu_16_04_home[/B][/COLOR][COLOR=#000000]/[/COLOR]

[/FONT]

[mr_raider]

Things you can do with btrfs

mr_raider@ThinkPad-11e ~ $ sudo btrfs subv list /
[sudo] password for mr_raider: 
ID 257 gen 26492 top level 5 path @xfce
ID 258 gen 26492 top level 5 path @xfcehome
ID 266 gen 29616 top level 5 path @
ID 267 gen 29618 top level 5 path @home
ID 286 gen 24746 top level 5 path timeshift-btrfs/snapshots/2017-11-26_09-37-17/@

Note that the program timeshift makes btrfs snapshots idiot proof.

[oshunluvr]

BTW I should have added to this thread - since the discussion involved disk space usage - My BTRFS file system, with SIX Linux installs, many snapshots, and HOME folders (in a separate subvolume) is consuming 194GB of a 460GB file system. This, my main BTRFS file system consists of two 250GB SSD's both of which have separate partitions for GRUB and SWAP. The remaining 230GB of each are joined as a single file system in RAID0 without need of another RAID tool like MDADM - something else you cannot do with EXT4.

[FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]/subvol[/B][/COLOR][COLOR=#000000]$ sudo btrfs fi sh[/COLOR]
[sudo] password for stuart:  
Label: 'ssd840pro'  uuid: 8f0c1661-4e84-4512-b875-23bcfd5be1d8
        Total devices 2 FS bytes used 193.95GiB
        devid    4 size 229.97GiB used 197.03GiB path /dev/sdc3
        devid    5 size 229.97GiB used 197.03GiB path /dev/sdd3

[/FONT]

[oshunluvr]

This highlights (pun not intended) the importance of verifying system backups are bootable. Having a system backup that you can’t boot from is as useful as not having one when yours goes TU. So you had to resort to a system backup that was four days old. How much user data might have been lost?

Absolutely correct. I realized if I had gone one more day without rebooting, I would have been restoring from a backup - luck prevailed in this instance. I've already started another thread to discuss this realization and a way to prevent this from happening again.

https://www.kubuntuforums.net/showth...napshot-script

However, no user data was at risk since the default BTRFS installation uses separate subvolumes for home vs. root, I reverted to a three-day old OS but still have today's home folders. Besides, even if home resided within the root subvolume, the data wasn't corrupted so I could have manually copied data files out of the still available but not-bootable subvolumes. I believe the boot is is kernel/nvidia driver related. The subvolume that eventually booted was prior to the last kernel and nvidia update. I'm going to clean up my snapshots and - AFTER making a fresh bootable snapshot - redo the full-upgrade and see if it was an anomaly or if something is actually broken in the update. I'll probably upgrade everything BUT the kernel and nvidia driver, then reboot. If all is well, snapshot again, and do the kernel and nvidia driver upgrades separately to see if either of them cause the problem to return. If not, I'll assume it was a fluke.

[Snowhog]

Lucky for me, my system automatically takes a daily snapshot every day and keeps the last three snapshots but deletes older ones. Along with that, I have 5 other installs on my system - which all are on the same btrfs file system, no partitioning required - so I booted into Manjaro and rolled back my KDEneon install to Tuedays, but it wouldn't boot either. Tried Monday, but also no-go. Finally booted to the Sunday snapshot - and I'm typing this reply.

This highlights (pun not intended) the importance of verifying system backups are bootable. Having a system backup that you can’t boot from is as useful as not having one when yours goes TU. So you had to resort to a system backup that was four days old. How much user data might have been lost?

[oshunluvr]

how much extra disk space does btrfs require ? in this case i work with 500 GB (second half of a 1 TB drive). i read ext4 should have some disk space empty to work well. but btrfs and zfs take up space for snapshots and such. i will definitelly put BTRFS on new PC (which will probably have larger drive size available) but in this case i think ext4 makes sense

I found this question interesting and a little confusing. Why would you assume btrfs takes more space?

Snapshots may consume space eventually (as you makes changes to the original subvolume) but take none initially, and snapshots aren't a mandatory action - you're not required to use them, but the functionality is available if you wish to use it. Of course, you're always able to delete a snapshot when you wish as well. The fact that EXT4 does not have snapshot capability doesn't mean it's somehow more efficient than BTRFS, it just has less functionality and features.

Just for informational purposes, I took a 30GB partition on one of my drives and formatted it with EXT4 and with BTRFS. Without a lot of detail, here's the available initial space report:

Format  Device          Size  Used  Free  %  Mount
EXT4:  /dev/sda3        30G   44M   28G   1% /mnt/test2
BTRFS: /dev/sda3        30G   17M   28G   1% /mnt/test2

So EXT4 takes more space initially.

Also, did you know that by default EXT4 also reserves 5% of drive space? So your 500GB drive is going to have 475GB available. This can be changed, but most people aren't even aware it happens. Bottom line though, if we're talking using this drive for a Kubuntu installation, you only need about 12-16GB worth of space. The file system overhead isn't really an issue with a drive that large.

BTW, rather coincidentally, I had to roll-back to a snapshot in order to boot this morning. I had rebooted last night, but gone to bed before checking to see if my system booted to the log in screen. When I went into my office, all I saw was a screen of text that ended in "kernel panic" - something I have not seen in a very long time. Apparently, something went wrong over the last two days with one of the updates - I haven't had time to try and figure out what.

Lucky for me, my system automatically takes a daily snapshot every day and keeps the last three snapshots but deletes older ones. Along with that, I have 5 other installs on my system - which all are on the same btrfs file system, no partitioning required - so I booted into Manjaro and rolled back my KDEneon install to Tuedays, but it wouldn't boot either. Tried Monday, but also no-go. Finally booted to the Sunday snapshot - and I'm typing this reply. Each rollback required a reboot, renaming the install and snapshot subvolumes, and rebooting again - that's it. The whole process to rollback 3 times took less than 10 minutes. Additionally, every Sunday my system makes an automatic backup to another drive that is also bootable, but I didn't need to go that far this time. I keep two weekly backups and older one are automatically deleted.

The point to telling you this is: None of this - snapshots, 6 installs to the same partition, automated bootable backups - is possible with EXT4. Of course, it's your system, so do what you want.

[mastablasta]

how much extra disk space does btrfs require ? in this case i work with 500 GB (second half of a 1 TB drive). i read ext4 should have some disk space empty to work well. but btrfs and zfs take up space for snapshots and such. i will definitelly put BTRFS on new PC (which will probably have larger drive size available) but in this case i think ext4 makes sense.

as for the old tech, i believe latest space probes utilised the PII processors - rigorously tested. while we don't have to go back in time so much, i don't have a problem using old tech if it works well. i used FAT32 on winXp for a very long time. unti they made descent recovery tools. and i was even saved by its use when partition got damaged by faulty drive cable.

my backups are manual (data on two different PC) as well as automated - using Areca to send versioned backups to family server. the server has RAID1 setup with mdadm, but i think i might have made a mistake unecessarilly added a complexity. i could have just send data to both disks. RAID is perhaps unnecessary and could not help the backups much. bad backup on one drive will just get mirrored on the other. it does protect against server drive failure a bit.
while various OS got imaged every once in a while and before doing an upgrade.

@mr_raider - i am still on 14.04 and plan to likely remain on it on at least one PC until early 2019. it has the original kernel and is there to give descent performance (power management and GPU performance) to the laptop which has an AMD Radeon card. My father was also kept on 14.04. works well for him.

another PC i have with 14.04, might do good with 16.04, so this one might get moved soon. but first i need to check if all drivers and such work. i had and still have troubles with sound on this motherboard. but they are not as big as they used to be in 13.10 and earlier.

[mr_raider]

I’m running Neon User Edition on Btrfs (a MUST) using nvidia-378 to drive my GT650M secondary GPU.

I’d recommend 16.04 until four months after the 21.04 final is released.

Five years on 16.04? That's harsh

[oshunluvr]

...but I really believe the supposed instability of EXT is somewhat exaggerated...

I myself, nor anyone else I've encountered, has referred to EXT4 as unstable that I am aware of. However, there were discussion in 2003-2006 about desired changes to EXT3 that might led to instability, so EXT4 was forked instead - with backward capability. I simply commented that EXT4 was outdated - and I'm not the only one who thinks so - from Wiki (emphasis added):

In 2008, the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that although ext4 has improved features, it is not a major advance, it uses old technology, and is a stop-gap.

Mr. Ts'o goes on to say:

Ts'o believes that Btrfs is the better direction because "it offers improvements in scalability, reliability, and ease of management". Btrfs also has "a number of the same design ideas that reiser3/4 had".

This was in 2008. I simply restated what the developer and maintainer of EXT3/4 has said.

Also, to be correct, I also did not refer at all to making backups. I referred to "snapshot" capability, something that does not exist in any iteration of EXT or almost any other file system. I did so to reference the concern the OP stated regarding potential problems associated with choosing or moving from 17.10 to 18.04. With BTRFS, in a few seconds, one can make a snapshot prior to any activity the user fears may be hazardous. If the fear becomes a reality, one than can revert to the snapshot in no more than a few seconds and a reboot. My experience has been like yours - I've rarely encountered (at least in the last 10 years) major problems associated with upgrades (I do not do release-upgrades at all, I prefer to install a new release along side). However, as one can easily tell by reading this forum, not all users experience trouble-free upgrading. With BTRFS, the concern is 100% removed. I snapshot prior to any upgrade so I can always revert. When it is clear all is well, I simply delete the snapshot. No one using EXT4 has that option. I totally agree that potential hardware failure requires a backup to protect your data, but I did not claim that snapshots constituted actual backups - just roll-back capability. I have no problem pointing out the numerous ways making backups with BTRFS is easier, quicker, safer, and more painless than with EXT4, but that really wasn't in the initial discussion.

Furthermore, I cannot think of anything EXT4 does better than BTRFS or any real reason to use it on a fixed drive (no need for BTRFS or EXT4 features on a thumb drive - I use EXT2 or VFAT for them) with a single exception: dynamical sized files. Dynamically sized files like VMware or Vbox virtual hard drives or swap files are not usable on any COW filesystem that I'm aware of. For that, you must use a swap partition and either put VM drives on a suitable filesystem, use fixed-size virtual drives, or apply NODATACOW to the file system containing the dynamic files.

You could argue that EXT4 performs slightly better in specific circumstances, but in real world terms at the user level, IME that's hardly noticeable if at all.

I can think of several reasons not to use EXT4: using multiple devices with LVM and RAID are a PITA to create and manage, the EXT4 file system does not honor "secure deletion", which overwrites deleted files, but sensitive data can remain in the file system journal, and simply the lack of features that modern file systems like BTRFS and ZFS have.

[jglen490]

It's not that I think BTRFS is unworthy, but I really believe the supposed instability of EXT is somewhat exaggerated. In my case I've been using EXT variants for over 15 years and except for an actual hardware failure (which wouldn't have been completely mitigated by BTRFS) I've not had any catastrophic problems with Linux updates or upgrades.

I don't rely on any "automatic" backup procedures - those inevitably result in excessive system administration time or failure of process. I don't like BTRFS, personally, because it takes up valuable space on the live environment - the snapshots still require care and feeding and monitoring, there is no backup system that doesn't. In the case of hardware failure, it doesn't matter what filesystem is in use at the time of failure, data is just as gone.

I backup my data routinely using (now) a rotating system of three external harddrives, it was two drives but I found another. In fairness, I don't have a tremendous amount of data - just under 75GB - which doesn't require much time to backup, and I DO NOT venture into the bleeding edge of anyone's software and that includes non-current kernels, alphas, betas, and non LTS versions. On top of that, I don't use an LTS until the first bug release (i.e., 16.04.1). So, yes, in that respect, I'm exceptionally "conservative" and I don't contribute to testing, either. On the other hand, I've had no unstable Linux platforms and unrecoverable updates/upgrades, with the exception of actual hardware failures, in a very long time.

If you choose to use BTRFS, that would be your choice, but make sure you still have a way to recover from hardware failure to the extent that you value your data and don't rely solely on snapshots stored on your active drive. Please note, I am not disrespecting anyone's choices, just be aware of potential concerns and plan accordingly.

[oshunluvr]

To GG's comment about btrfs...You hear about failed updates and upgrades all the time. Why risk it by using an outdated filesystem like EXT? With BTRFS, you need only take a snapshot before updating or doing a version upgrade and if it breaks your install - roll back to your previous state. Something to consider.

[mastablasta]

thanks. i think btrfs will be on the new PC i am collecting money for. this one will be a mix of ext4 & NTFS. "only" 500 GB will be set aside for linux OS and linux data. the other data drive is 1 TB NTFS and ofcourse the windows side of the OS drive is also NTFS on 3 partitions.

i went scavenging around drawers and managed to find 2 old 16 GB USB drives. one of them can be used to install and test the OS & drivers. if all goes well i will do the install. otherwise i will use some light linux with browser in virtualbox for browsing in winXP. slower option but kind of safe.

yes i think it will be best to start with 16.04.3. the point release (.3) has "latest" kernel that get's upgraded, then see how it goes with drivers and such.

if there is much snow outside (as in the forecast) then this weekend will be the time to test it otherwise it will have to wait until the holidays, but at least i got a couple of good ideas on how to go about this.

[GreyGeek]

what is the Installed OS size and which version should i choose

I’m running Neon User Edition on Btrfs (a MUST) using nvidia-378 to drive my GT650M secondary GPU.

I’d recommend 16.04 until four months after the 21.04 final is released.
https://wiki.ubuntu.com/Releases
Then I’d do a fresh install, not an upgrade. Using Btrfs a bkup is trivial and restoring your data takes only minutes.


Sent from my iPhone using Tapatalk