View previous topic :: View next topic |
Author |
Message |
ToeiRei Veteran
Joined: 03 Jan 2005 Posts: 1191 Location: Austria
|
Posted: Wed Jun 30, 2010 2:36 pm Post subject: |
|
|
I didn't give up yet as the system feels better with the latest patchset. _________________ Please stand by - The mailer daemon is busy burning your messages in hell... |
|
Back to top |
|
|
Dont Panic Guru
Joined: 20 Jun 2007 Posts: 322 Location: SouthEast U.S.A.
|
Posted: Wed Jun 30, 2010 5:12 pm Post subject: |
|
|
I haven't given up on Btrfs yet either.
But, on the other hand, I don't consider Btrfs anywhere near stable.
I don't want to be seen as flaming Btrfs, because I still think it has some really cool potential. But I think many users who are considering adopting Btrfs would be better served by a more honest appraisal of Btrfs' current stage of development.
I think people assume it's production ready just because it's in the stable kernel. But Btrfs is still under heavy development.
I remember how ext4 was getting flamed during the period it was calling itself "ext4-dev" in the kernel tree. Some people felt the transition from ext4-dev to ext4 was not smooth enough, and introduced some issues. But at least is was clear the ext4 was still in the developmental phase.
Btrfs is no-where near as stable as ext4 was when they dropped the "-dev" tag. There's a long list of issues to be addressed and features to be added that will continue to hold Btrfs under heavy development for the immediate future. Btrfs hasn't even finished writing it's fsck application yet.
I would like to see Btrfs be feature complete, and with far fewer issues rolling across the Mailing List before even trying to decide if it's ready for the "stable" label. |
|
Back to top |
|
|
ToeiRei Veteran
Joined: 03 Jan 2005 Posts: 1191 Location: Austria
|
Posted: Wed Jun 30, 2010 9:04 pm Post subject: |
|
|
Well... I'm using it here since quite a while on a single disk and didn't loose any data. For me it's quite stable and compression is a bliss as seen on portage. But I agree with keeping it away from the productive systems as there's no support for grub in example.
I'm curious about the next changes they'll do and how to migrate _________________ Please stand by - The mailer daemon is busy burning your messages in hell... |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Jun 30, 2010 10:19 pm Post subject: |
|
|
I am not flaming BTRFS. Just pointing out that it remains half-baked at this time. They need to cook it more before masses use it. Too early an adoption can backfire on BTRFS. |
|
Back to top |
|
|
Simba7 l33t
Joined: 22 Jan 2007 Posts: 706 Location: Billings, MT, USA
|
Posted: Thu Jul 01, 2010 2:22 am Post subject: |
|
|
ToeiRei wrote: | Well... I'm using it here since quite a while on a single disk and didn't loose any data. For me it's quite stable and compression is a bliss as seen on portage. But I agree with keeping it away from the productive systems as there's no support for grub in example. |
I'm using it on 7 systems at the moment. Three remote servers, my router, my Portage server, my Cacti Server, and one other server. I also have it running on a PowerEdge 2950 at the local University. All the systems are using compression.
I'm still sticking with ext3 on the /boot partition. It seems to run flawlessly using that config. I run btrfs on everything else. |
|
Back to top |
|
|
Shining Arcanine Veteran
Joined: 24 Sep 2009 Posts: 1110
|
Posted: Thu Jul 01, 2010 3:35 am Post subject: |
|
|
Simba7 wrote: | ToeiRei wrote: | Well... I'm using it here since quite a while on a single disk and didn't loose any data. For me it's quite stable and compression is a bliss as seen on portage. But I agree with keeping it away from the productive systems as there's no support for grub in example. |
I'm using it on 7 systems at the moment. Three remote servers, my router, my Portage server, my Cacti Server, and one other server. I also have it running on a PowerEdge 2950 at the local University. All the systems are using compression.
I'm still sticking with ext3 on the /boot partition. It seems to run flawlessly using that config. I run btrfs on everything else. |
Btrfs seems to be either hit or miss for people. |
|
Back to top |
|
|
cach0rr0 Bodhisattva
Joined: 13 Nov 2008 Posts: 4123 Location: Houston, Republic of Texas
|
Posted: Thu Jul 01, 2010 3:40 am Post subject: |
|
|
Shining Arcanine wrote: |
Btrfs seems to be either hit or miss for people. |
pretty well been my experience. Brilliant on one laptop, terrible on the workstation/server where it sits atop dm-crypt vols. |
|
Back to top |
|
|
ToeiRei Veteran
Joined: 03 Jan 2005 Posts: 1191 Location: Austria
|
Posted: Thu Jul 01, 2010 4:46 pm Post subject: |
|
|
I agree. My PC is a laptop. _________________ Please stand by - The mailer daemon is busy burning your messages in hell... |
|
Back to top |
|
|
Shining Arcanine Veteran
Joined: 24 Sep 2009 Posts: 1110
|
Posted: Thu Jul 01, 2010 5:10 pm Post subject: |
|
|
It was a disaster on my laptop with 2.6.33 RC 4. |
|
Back to top |
|
|
ToeiRei Veteran
Joined: 03 Jan 2005 Posts: 1191 Location: Austria
|
Posted: Thu Jul 01, 2010 5:19 pm Post subject: |
|
|
.34 or .35-rc3 had many bugfixes. So I can't complain _________________ Please stand by - The mailer daemon is busy burning your messages in hell... |
|
Back to top |
|
|
Shining Arcanine Veteran
Joined: 24 Sep 2009 Posts: 1110
|
Posted: Thu Jul 01, 2010 7:56 pm Post subject: |
|
|
ToeiRei wrote: | .34 or .35-rc3 had many bugfixes. So I can't complain |
I do not plan to use it until it is considered stable for production environments at the earliest, regardless of what success other people are having with it. I cannot afford to have my system's file system be rendered unusable by undeletable files or other kinds of weirdness. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Thu Jul 01, 2010 8:12 pm Post subject: |
|
|
Shining Arcanine wrote: | ToeiRei wrote: | .34 or .35-rc3 had many bugfixes. So I can't complain |
I do not plan to use it until it is considered stable for production environments at the earliest, regardless of what success other people are having with it. I cannot afford to have my system's file system be rendered unusable by undeletable files or other kinds of weirdness. | Major issue for me is lack of fsck. I suffered hidden corruptions twice and I could not get anything about it from fsck. No message about mismatch of checksums for those file when I tried to read them in 'dmesg'. What good are checksums if they are not used to verify and report on the integrity of data. |
|
Back to top |
|
|
ToeiRei Veteran
Joined: 03 Jan 2005 Posts: 1191 Location: Austria
|
Posted: Thu Jul 01, 2010 8:23 pm Post subject: |
|
|
I use to 'touch' the files and check against dmesg. That way I can see corruptions and act. Another good way is a tarball across the whole subvolume. (which are also good backups) _________________ Please stand by - The mailer daemon is busy burning your messages in hell... |
|
Back to top |
|
|
dufeu l33t
Joined: 30 Aug 2002 Posts: 924 Location: US-FL-EST
|
Posted: Fri Jul 09, 2010 6:47 pm Post subject: |
|
|
As has been noted here and elsewhere, btrfs is under heavy development.
I have a couple of thoughts I thought I'd throw out.
- Heavy development means just that. Anyone who sets up a completely btrfs based system is, in my book, a complete foole. Why? Because there are so many potential areas for problems to arise that it becomes impossible for any sane human to figure out what's going on. The best approach is to always install the simplest or near simplest case and go from there. I shake my head in disbelief at people who use btrfs in their '/' partition. Give me a break people! How do you figure out which problem (of many) you're looking at?
- When anything is under heavy development, being subscribed to the mailing list makes good sense. It doesn't matter if you understand less than one word in 10, there's still a lot of information to be gleaned from perusing the list. If you're following the thread here and thinking about installing btrfs or actually have an active btrfs based device, you should be subscribed to the mailing list too. Why? Not only can you get a sense of what's not working yet or what new features are currently being worked on, but you can get an idea of what's currently broken. This is valuable to know folks! If you have an active btrfs based partition and you're not subscribed to the list, I'm virtually rolling my eyes and shaking my head at you. Really.
- Always have a plan. Whenever you try something new, always ask yourself "What's the plan?" and then ask yourself "If it blows up, what's the fallback?" Why? You mean to tell me you're installing btrfs because it's "shiny?" {ooooh. Shiney! Must have/install!} {rolls eyes} {shakes head}
I'm taking the plunge with btrfs. Here's my 'plan'. The 'fallbacks' should be obvious. Note: each step in this list does have a fallback!
- Install btrfs on a single free partition on a non-critical drive. Rationale? Get practice with mkfs.btrfs. Get some practical understanding of some of the available options. {Done}
- Set up a simple files only server with multiple drives and a single instance of btrfs across those drives. Rationale? See how btrfs works across multiple devices in a relatively simple setting. {In Progress}
- Get more experience of what's involved. Write "How-To documentation". Why? Because writing down your experiences in the form of a How-to is an excellent tool for revealing shortfalls and/or misunderstandings of official documentation. {In Progress}
- Set up a more complex server. In addition to setting up a files serving partition based on btrfs, add things like '/var' and '/usr/portage/distfiles'. Rationale? The idea is to start stressing the btrfs service a bit more but still have a system you can recover if worst comes to worst. {Future}
- Set up a simple workstation for a non-techy user. Rational? This is where you finally should be trying out btrfs on '/' for the first time. There is a lot of wildy variant activity that happens at '/' as well as things like sockets, device nodes, etc. Far better to give a relatively lightweight user the first machine with '/' housed on a btrfs partition. It gives you a much better chance to see possible shortcomings. And it's easy to swap out a light weight system for something more stable if you need to. An understanding user who's co-operating with you will go a long way towards keeping stress out of your life. {Future}
- Set up a simple files only server with '/' on a btrfs based partition. Rationale? Assuming all the above has progressed reasonably well, now you can start taking a few, limited risks. {Future}
- And so on. Rationale? The idea is to break your risks down into manageable chunks. This is a critical concept. Never let your sense of "Shiny! Must have!" talk you into attempting to swallow chunks of risk you can't deal with.
OK. The above was a mouthful. This is what I've actually done/am doing:- On my primary PC, I replaced the smallest drive (hd0) with a larger drive. The first 3 partitions on the drive are exact duplicates of the partitions of the drive that was replaced. The last partition was formated for btrfs and mounted as '/pub00'. This is where I tried out different mkfs.btrfs options etc. I did some initial copies of files to and from this partition. Note that no critical data or system files were involved at any time. This is where I also checked things like the functioning of nfs availability through /etc/exports and also determined what is involved in adding this partition to /etc/fstab. This is what linux reports about my primary PC hard drives:
Code: | brw-rw---- 1 root disk 8, 0 Jul 8 16:56 /dev/sda
brw-rw---- 1 root disk 8, 1 Jul 8 20:56 /dev/sda1
brw-rw---- 1 root disk 8, 2 Jul 8 16:56 /dev/sda2
brw-rw---- 1 root disk 8, 3 Jul 8 20:56 /dev/sda3
brw-rw---- 1 root disk 8, 4 Jul 8 16:56 /dev/sda4
brw-rw---- 1 root disk 8, 16 Jul 8 16:56 /dev/sdb
brw-rw---- 1 root disk 8, 17 Jul 8 20:56 /dev/sdb1
brw-rw---- 1 root disk 8, 32 Jul 8 16:56 /dev/sdc
brw-rw---- 1 root disk 8, 33 Jul 8 20:56 /dev/sdc1
brw-rw---- 1 root disk 8, 48 Jul 8 16:56 /dev/sdd
brw-rw---- 1 root disk 8, 49 Jul 8 20:56 /dev/sdd1
brw-rw---- 1 root disk 8, 64 Jul 8 16:56 /dev/sde
brw-rw---- 1 root disk 8, 65 Jul 8 20:56 /dev/sde1 |
This is what btrfs-show reports: Code: | Label: none uuid: 079dc77d-7ac7-43c7-b282-e09964d25eea
Total devices 1 FS bytes used 513.61GB
devid 1 size 558.90GB used 558.90GB path /dev/sda4
Btrfs v0.19-13-gb72e4c4-dirty |
This is what the /etc/fstab entry looks like: Code: | /dev/sda4 /pub00 btrfs noatime 0 1 |
I created a single device/partition btrfs using all default options. i.e. Code: | mkfs.btrfs /dev/sda4 |
If I've understood the available documentation correctly, this means that I've created a 'raid0' single device/partition btrfs with 2 copies of the meta data on /dev/sda4. Everything seems to work pretty much as expected. There are some observed "gotchas" I'll note below.
I have a file server set up at my mother's house. It serves several important but non-critical functions. First, it serves as my personal backup for all the data I have on my personal workstation and laptops. I really do back up my systems and I really do have at least two copies of everything on at least two different systems. This includes all all the CDs and DVDs I've ripped from our personal collections as well as our collection of ebooks. {Thanks Project Gutenberg! Thanks Internet Archive!}
Lately, we've had a number of power spikes at my mother's house due to lightning storms {she's located in Florida, US}. Lost a monitor, keyboard, mouse and attached electronic KVM switch. After looking over the server, I decided it was time to rebuild it. So I'm taking this opportunity to set up a simple btrfs based file server. The configuration is a total of 6 hard drives. The disk configuration looks like this: Code: | brw-rw---- 1 root disk 8, 0 Jul 6 08:34 /dev/sda
brw-rw---- 1 root disk 8, 16 Jul 6 08:34 /dev/sdb
brw-rw---- 1 root disk 8, 32 Jul 6 08:34 /dev/sdc
brw-rw---- 1 root disk 8, 48 Jul 6 08:34 /dev/sdd
brw-rw---- 1 root disk 8, 64 Jul 6 08:34 /dev/sde
brw-rw---- 1 root disk 8, 65 Jul 6 12:34 /dev/sde1
brw-rw---- 1 root disk 8, 66 Jul 6 08:34 /dev/sde2
brw-rw---- 1 root disk 8, 67 Jul 6 12:34 /dev/sde3
brw-rw---- 1 root disk 8, 80 Jul 6 08:34 /dev/sdf
brw-rw---- 1 root disk 8, 96 Jul 6 08:34 /dev/sdg |
This is what btrfs-show reports: Code: | Label: PUBLIC uuid: b71c7140-e845-4891-a8c9-98599be7d29c
Total devices 5 FS bytes used 1.34TB
devid 2 size 465.76GB used 372.00GB path /dev/sdb
devid 5 size 233.76GB used 233.01GB path /dev/sdf
devid 1 size 465.76GB used 371.02GB path /dev/sda
devid 4 size 931.51GB used 372.26GB path /dev/sdd
devid 3 size 931.51GB used 373.25GB path /dev/sdc
Btrfs v0.19-13-gb72e4c4-dirty |
To create this server, I booted with 'System Rescue CD 1.5.6'. The sysrecuecd boots showing disks in traditional order. i.e. This PC has a PATA controller and 2 of the 6 disks are installed on it rather than all SATA. The /dev/sd# order of the boot disk is therefore different from the order I show here. I created the btrfs instance from the boot CD. So the command I show doesn't make sense for the results I display. This is the command I used to create the btrfs instance: Code: | mkfs.btrfs -L PUBLIC /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf | where sda and sdb were the PATA drives and sdc, sdd, sde and sdf were the SATA drives.
These are the relevant /etc/fstab entries: Code: | /dev/sde1 /boot ext2 noauto,noatime 1 2
/dev/sde2 none swap sw,pri=1 0 0
/dev/sde3 / ext4 noatime 0 1
/dev/disk/by-label/PUBLIC /public btrfs noauto,noatime 0 1 |
Note that '/', and by extension, '/usr', '/var', '/dev' and all other system directories/files are not on the btrfs based partition. I can't stress this enough. The idea is take a reasonable plunge in relatively calm water. The idea is not to jump off a pier while high tide is going out with the presence of powerful riptides.
I'm still in the process of backing up files onto the server. Note that one of the hard drives is already full. I'll be checking the effectiveness of 're-balancing' later.
I deliberately went with un-even sized drives because 1) I'm not buying any thing new and this is what I have and 2) I really want to see how well btrfs handles this situation since this is a design goal.
Now for a few 'gotchas' in no particular order:- You cannot create a btrfs instance and the go back to apply a label to it. i.e.
Code: | mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
mkfs.btrfs -L PUBLIC /dev/sdb |
What happens is that you end up with just /dev/sdb in the btrfs instance: Code: | Label: PUBLIC uuid: b71c7140-e845-4891-a8c9-98599be7d29c
Total devices 1 FS bytes used 0.01GB
devid 1 size 233.76GB used 0.01GB path /dev/sdb |
Once you see this in action, it makes sense. The progam is working as designed. But, this is an area I intend to explore further. In other file systems, applying a label to a disk has no effect on the partition instance. Since it's not clearly covered that the designed behavior is different from possible assumptions, you can really shoot yourself in the foot here.
In GUI based file managers, you'll find that you probably won't be able to write to most directories in a btrfs based instance without doing come CLI work with 'chmod' first. This is one of those areas under active development. This can result in all kinds of unexpected failures from programs expecting to write to or execute from a btrfs instance. You have been warned.
Apparently, by using raw /dev/sd# devices, the btrfs instance I show here won't automatically mount. Rather than go nuts with that, I turned off automount "-o noauto" in the /etc/fstab file. Instead, I added the following to /etc/conf.d/localmount: Code: | btrfsctl -a &>/dev/null
mount /public |
I'll be looking into this further. But not just yet.
I've written this long post so that you all can get an idea of the real world state of btrfs. It's works well enough for some real and interesting testing but not well enough for critical production installation. If you have non-critical PCs available to you, you can start like I'm doing to get a feel for it. So far, I will say I'm very pleased with what limited functional use I'm making of it. In the limited server environment I'm setting up, I think it will be a big improvement. But realize just how limited my installation is. There are only two users with no more than 8 computers able to pull data from it at any one time. This is not what you could call a 'mission critical' application. If I loose the server, it's not really a problem as I have copies of everything. So I get some valid real world testing at almost no risk.
Enjoy! _________________ People whom think M$ is mediocre, don't know the half of it. |
|
Back to top |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Mon Aug 02, 2010 2:44 pm Post subject: |
|
|
i was quite happy with btrfs until a few days ago.
For some reason all the btrfs-* kernel daemons started to suck _a lot_ of cpu, rendering the box almost useless. I mean, just quiting htop could take 3 or 4 seconds f.ex. , firefox autocompletion could easily take 10 seconds, etc.
I tried to track down from where this could have come from ( initially i suspected it was firefox but it wasnt), upgrading the kernel made no difference either.
Now after reformating everything is normal again, did anyone have the same experience ?
cheers |
|
Back to top |
|
|
dufeu l33t
Joined: 30 Aug 2002 Posts: 924 Location: US-FL-EST
|
Posted: Mon Aug 02, 2010 4:27 pm Post subject: |
|
|
gringo wrote: | i was quite happy with btrfs until a few days ago.
For some reason all the btrfs-* kernel daemons started to suck _a lot_ of cpu, rendering the box almost useless. I mean, just quiting htop could take 3 or 4 seconds f.ex. , firefox autocompletion could easily take 10 seconds, etc.
I tried to track down from where this could have come from ( initially i suspected it was firefox but it wasnt), upgrading the kernel made no difference either.
Now after reformating everything is normal again, did anyone have the same experience ?
cheers |
Running btrfs on 3 different systems. On two systems, I'm running a multi device btrfs setup. On the third, I'm running btrfs on a single partition.
I am NOT running btrfs on my "root" partition on any of the three systems.
No - I haven't seen anything like that at this time. _________________ People whom think M$ is mediocre, don't know the half of it. |
|
Back to top |
|
|
regomodo Guru
Joined: 25 Mar 2008 Posts: 445
|
Posted: Tue Aug 03, 2010 5:40 pm Post subject: |
|
|
I've finally had enough of btrfs. My multi-device setup has broken for no reason and my patience has run out with it. Back to raid0 ext4. |
|
Back to top |
|
|
Letharion Veteran
Joined: 13 Jun 2005 Posts: 1344 Location: Sweden
|
Posted: Thu Aug 05, 2010 9:07 am Post subject: |
|
|
I have a strange bug with hardlinks, and I'm wondering if it's possibly related to btrfs.
I hope to attract some attention to https://bugs.gentoo.org/show_bug.cgi?id=329981 from someone with more btrfs knowledge than I have. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Thu Aug 05, 2010 2:04 pm Post subject: |
|
|
gringo wrote: | Now after reformating everything is normal again | I know with ZFS, periodic scrubbing is recommended. Perhaps something similar with btrfs? _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Thu Aug 05, 2010 7:46 pm Post subject: |
|
|
Maybe that is the actual problem. Deterioration over time. Since formatting "fixed" the problem.
I guess it depends on how long it took to reach that state, and whether or not a comprable time frame will lead to the same result.
EDIT: Split off from the original thread... seemed like a good demarcation. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
Simba7 l33t
Joined: 22 Jan 2007 Posts: 706 Location: Billings, MT, USA
|
Posted: Tue Aug 10, 2010 4:19 am Post subject: |
|
|
kernelOfTruth wrote: | meanwhile ZFS FTW ! |
I'd love to run it, but I'd have to switch a couple systems back to FreeBSD (which is tempting at times). |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
dufeu l33t
Joined: 30 Aug 2002 Posts: 924 Location: US-FL-EST
|
Posted: Wed Aug 11, 2010 12:05 am Post subject: |
|
|
kernelOfTruth wrote: | pjp wrote: | gringo wrote: | Now after reformating everything is normal again | I know with ZFS, periodic scrubbing is recommended. Perhaps something similar with btrfs? |
afaik online checking or even offline checking isn't fully possible yet for btrfs |
The btrfs wiki documentation hasn't been updated yet. The defrag command for btrfs is: Code: | btrfs filesystem defrag <file>|<dir> [<file>|<dir>...] |
More information can be had from the man pages:
I haven't tried it yet but I expect to try it soon. I need to both defrag and re-balance on one of my experimental servers. Example: Code: | # btrfs filesystem show
failed to read /dev/sr0
failed to read /dev/pktcdvd/pktcdvd0
failed to read /dev/pktcdvd/sr0
Label: none uuid: 079dc77d-7ac7-43c7-b282-e09964d25eea
Total devices 1 FS bytes used 523.05GB
devid 1 size 558.90GB used 558.90GB path /dev/sda4
Btrfs v0.19-16-g075587c-dirty
# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 380497160 305378364 55790596 85% /
/dev/root 380497160 305378364 55790596 85% /
rc-svcdir 1024 136 888 14% /lib64/rc/init.d
udev 10240 232 10008 3% /dev
shm 4090624 1096 4089528 1% /dev/shm
/dev/sdb1 961432072 765411128 196020944 80% /home
/dev/sda4 586051200 549195176 36856024 94% /pub00 <=====
/dev/sdc1 961432072 957611844 1378328 100% /pub01
/dev/sdd1 961432072 903971612 8622460 100% /pub02
/dev/sde1 961432072 904381420 8212652 100% /pub03
# btrfs filesystem defragment /pub00
# btrfs filesystem balance /pub00 |
Important note! The version of btrfs-progs in portage is not yet the version which includes the new btrfs commands. Use btrfs-progs-9999 to get the latest unstable updates! _________________ People whom think M$ is mediocre, don't know the half of it. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Aug 11, 2010 1:51 am Post subject: |
|
|
I got an SSD for my laptop today so I thought I'd take a risk and use a single big btrfs root partition (+ ext4 /boot).
Few short questions:
If it's mounted with -o=ssd already, will I gain anything at all by having laptop-mode enabled too?
How big's /usr/portage with compression? Also, is it smart enough to leave uncompressable things alone?
Can I do anything useful with subvolumes on a setup like this? |
|
Back to top |
|
|
|