| View previous topic :: View next topic |
| Author |
Message |
nixnut
Bodhisattva
Joined: 09 Apr 2004
Posts: 10974
Location: the dutch mountains
|
 Posted: Sun Mar 13, 2011 6:22 pm Post subject: |
 |
|
merged some posts above
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
| Back to top |
|
 |
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Sun Mar 13, 2011 10:19 pm Post subject: |
|
|
There are a couple of cool and new features on the mailing list. Hope to see some of the patches merged into the btrfs-progs too...
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
Letharion
Veteran
Joined: 13 Jun 2005
Posts: 1344
Location: Sweden
|
| Posted: Sat Mar 26, 2011 3:43 pm Post subject: Booting to a btrfs raid? |
|
|
I put in two new drives, then
| Code: | mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc
mount /dev/sdb /mnt/gentoo |
and copied my / to /mnt/gentoo. Now I'm trying to boot up on this. Grub and the kernel is still on my older drive, so that part works well, but when I try to pass of /dev/sd{b,c} as root devices to the kernel it complains that the root device cannot be mounted. My current root is btrfs as well, so I know the kernel can handle it, but my raid setup probably requires something more to work. I'm somewhat surprised I can't find it mentioned on google how to do this 
Last edited by Letharion on Sun Apr 17, 2011 4:31 pm; edited 1 time in total |
|
| Back to top |
|
|
jbouzan
Tux's lil' helper
Joined: 23 Nov 2007
Posts: 138
|
| Posted: Sun Mar 27, 2011 1:34 am Post subject: |
|
|
| Dont Panic wrote: | | gringo wrote: | i´m now on current git and updated to unstable and yes i´m seeing mayor hiccups here.
Just to make sure i understand the problem : does this only happen with compression enabled ? |
The corruptions that occur when copying/moving cross-fs seem to only be occuring on compressed btrfs file systems.
You also need to be using the newest sys-apps/coreutils. If you're using the stable (for now) sys-apps/coreutils-8.7, you shouldn't see the corruptions.
Having said that, the bug that is surfacing has the potential to crop up somewhere else until it is fixed. |
The problem is only compressed btrfs? I'm having an issue when copying files from an uncompressed btrfs, using a 2.6.37 pf-sources kernel and coreutils 8.10. Using cp to copy videos from btrfs to an ext4 drive, a significant portion of the files are corrupted. I've started to always use md5sum to check what ends up on the ext4 is the same as the source. Since I only use btrfs on a partition that holds dvd rips, I'm thinking of copying the files somewhere and using a different filesystem. Is there a simple command that would copy everything off that partition and verify a checksum of all the written files? |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Sun Mar 27, 2011 1:29 pm Post subject: |
|
|
| jbouzan wrote: | | Dont Panic wrote: | | gringo wrote: | i´m now on current git and updated to unstable and yes i´m seeing mayor hiccups here.
Just to make sure i understand the problem : does this only happen with compression enabled ? |
The corruptions that occur when copying/moving cross-fs seem to only be occuring on compressed btrfs file systems.
You also need to be using the newest sys-apps/coreutils. If you're using the stable (for now) sys-apps/coreutils-8.7, you shouldn't see the corruptions.
Having said that, the bug that is surfacing has the potential to crop up somewhere else until it is fixed. |
The problem is only compressed btrfs? I'm having an issue when copying files from an uncompressed btrfs, using a 2.6.37 pf-sources kernel and coreutils 8.10. Using cp to copy videos from btrfs to an ext4 drive, a significant portion of the files are corrupted. I've started to always use md5sum to check what ends up on the ext4 is the same as the source. Since I only use btrfs on a partition that holds dvd rips, I'm thinking of copying the files somewhere and using a different filesystem. Is there a simple command that would copy everything off that partition and verify a checksum of all the written files? |
rsync with checksumming ? 
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004  |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
idella4
Retired Dev
Joined: 09 Jun 2006
Posts: 1600
Location: Australia, Perth
|
| Posted: Mon Apr 04, 2011 10:14 am Post subject: |
|
|
Letharion,
I'm surprised you've not got a reply yet.
You probably already have it so but make sure your btrfs is compiled as loadable modules in your kernel, NOT built in.
If it's raid related, I don't know anything about raid.
_________________
idella4@aus |
|
| Back to top |
|
|
Dont Panic
Guru
Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.
|
| Posted: Mon Apr 04, 2011 5:15 pm Post subject: |
|
|
| kernelOfTruth wrote: | I'd like to upgrade btrfs of my 2.6.37.6 based kernel to latest state
I've unfortunately forgotten which commit resembled the btrfs-state from 2.6.37 |
I may not be understanding your question correctly, but you can browse the git source for the 2.6.37 kernel, and grab a snapshot of just the fs/btrfs directory by calling up a tree, and clicking on the 'fs' directory, and then the 'btrfs' directory.
However, only a select few important patches have been backported to the 2.6.37 tree from the 2.6.38 btrfs patchset.
If you want to backport all the 2.6.38 btrfs patches to the 2.6.37 kernel, that's a bigger chore. I was keeping my 2.6.37 kernel up-to-date with the 2.6.38_rc patches, but I've since moved on to the 2.6.38 kernel. |
|
| Back to top |
|
|
Simba7
l33t
Joined: 22 Jan 2007
Posts: 706
Location: Billings, MT, USA
|
| Posted: Sat Apr 09, 2011 3:18 pm Post subject: |
|
|
I would not suggest even upgrading your kernel past 2.6.36 if you use BTRFS. I'm having some serious issues here, too.
One is, I can't compile a stage1 without running out of room... on a 10GB Hard drive. I have *NEVER* had this issue before (even on an old 2GB), and I'm quite irritated on what broke between then and now. This is during the "emerge -e system" stage, usually when compiling GCC (lots of little files).
Second is, it's rather easy to crash. I'm finding this out on a few systems, mostly my TS Mini (using SoftRAID).
I'm switching them all back to either .35 or .36 until something gets fixed. I don't really want to ditch BTRFS altogether, but I might have to.
EDIT: I'll try using an earlier version of coreutils and see if the results are the same. |
|
| Back to top |
|
|
Letharion
Veteran
Joined: 13 Jun 2005
Posts: 1344
Location: Sweden
|
| Posted: Sun Apr 10, 2011 10:11 am Post subject: |
|
|
| idella4 wrote: | Letharion,
I'm surprised you've not got a reply yet. |
I was a bit surprised as well, but as it turns out, one if the discs I did the raid on was probably broken. I replaced it and things have since worked better. This however, leads me to a new question.
| Code: | # mount | grep "on / "
/dev/sdb on / type btrfs (rw,noatime)
# btrfs fi df /
Data, RAID1: total=259.00GB, used=256.64GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=44.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=4.50GB, used=1.27GB
Metadata: total=8.00MB, used=0.00
# btrfs fi show
Label: none uuid: c6c89292-ea29-484c-ad29-9003a5fedf90
Total devices 2 FS bytes used 257.93GB
devid 1 size 931.51GB used 263.53GB path /dev/sdb
devid 2 size 931.51GB used 263.51GB path /dev/sdc
Label: none uuid: 6f2f8317-3012-4e79-a82d-ab2e8eaa6cd6
Total devices 1 FS bytes used 354.99GB
devid 1 size 465.65GB used 465.65GB path /dev/sda2
|
My interpretation of the above data is that /dev/sdb and /dev/sdc are exact mirrors of each other, and contain my / root partition.
This would make complete sense if it wasn't for the fact that I've copied all the data from /dev/sda2 onto /dev/sdb. From the information above, it looks like the data has been split like in raid-0, instead of the what I expect, mirrored like in raid-1.
I tried reading the FAQ about "Why are there so many ways to check the amount of free space?" hoping this would make it more clear, but it doesn't. Can anyone tell me what's going on? |
|
| Back to top |
|
|
Dont Panic
Guru
Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.
|
| Posted: Tue Apr 12, 2011 1:06 pm Post subject: |
|
|
| Simba7 wrote: | One is, I can't compile a stage1 without running out of room... on a 10GB Hard drive. I have *NEVER* had this issue before (even on an old 2GB), and I'm quite irritated on what broke between then and now. This is during the "emerge -e system" stage, usually when compiling GCC (lots of little files).
Second is, it's rather easy to crash. I'm finding this out on a few systems, mostly my TS Mini (using SoftRAID). |
For your first problem, this sounds like the latest issue with space_cache.
Have you ever mounted btrfs with the "-o space_cache" option? If so, you may need to occasionally remount with "-o clear_cache". There's a bug in the space_cache code (fixed in the 2.6.39_rc kernel) that would lead to the cache not releasing space back. Even with the patch in 2.6.39_rc kernels, you'd need to mount with "-o clear_cache" to clear out past allocations.
As far as you second problem, sorry, I have no clue. |
|
| Back to top |
|
|
lkraav
Tux's lil' helper
Joined: 13 Oct 2004
Posts: 129
Location: Estonia
|
| Posted: Tue Apr 12, 2011 1:20 pm Post subject: |
|
|
hope you guys dont me asking here, looks like this thread is a bit more live compared to my OP @ https://bbs.archlinux.org/viewtopic.php?pid=915545#p915545
any negative feedback or gotchas on this setup?
* distribute 40gigs into 4 partitions
* encrypt them with dm-crypt
* join 2 crypted partitions for /root
* join 2 crypted partitions for /home
* leave 20 gigs for /pub random unencrypted storage, -o discard
i'm not fully able to picture how TRIM works, will work or doesn't work for this setup.
it will be fine on /pub.
but what will happen inside the crypted areas in dm-crypt's current state regarding also ssd built-in garbage collection?
should i mount my btrfs -o ssd or ssd_spread or nothing when sitting on top of dm-crypt?
how will the processes change when dm-crypt will get support for TRIM?
-o noatime,nodiratime,compress are still good idea probably (https://forums.gentoo.org/viewtopic-p-6 … ml#6347333)? |
|
| Back to top |
|
|
idella4
Retired Dev
Joined: 09 Jun 2006
Posts: 1600
Location: Australia, Perth
|
| Posted: Fri Apr 15, 2011 10:47 am Post subject: |
|
|
Simba7,
WHAT IS YOUR STATUS?
btrfs has never yet been able to get volume sizes right, but if you give it a big buffer it should get by.
Please clarify crash, could mean anything. Why are you assuming the newer kernel is at fault? I thought they were as bad as each other in only minor differing ways.
_________________
idella4@aus |
|
| Back to top |
|
|
Simba7
l33t
Joined: 22 Jan 2007
Posts: 706
Location: Billings, MT, USA
|
| Posted: Sat Apr 16, 2011 8:28 pm Post subject: |
|
|
| idella4 wrote: | Simba7,
WHAT IS YOUR STATUS?
btrfs has never yet been able to get volume sizes right, but if you give it a big buffer it should get by.
Please clarify crash, could mean anything. Why are you assuming the newer kernel is at fault? I thought they were as bad as each other in only minor differing ways. |
Still stuck. I've been using "-o compress-force" and that's it during the stage1 install. I tried it again with 2.6.36 and it's running great without "out of space" issues.. even on a 2GB partition.
| Dont Panic wrote: | For your first problem, this sounds like the latest issue with space_cache.
Have you ever mounted btrfs with the "-o space_cache" option? If so, you may need to occasionally remount with "-o clear_cache". There's a bug in the space_cache code (fixed in the 2.6.39_rc kernel) that would lead to the cache not releasing space back. Even with the patch in 2.6.39_rc kernels, you'd need to mount with "-o clear_cache" to clear out past allocations. |
No, I never had used the space_cache option before.
..as for it crashing, I'm suspecting the culprit is about 3 feet tall. I guess he's been unplugging it and plugging it back in when his mom's doing other things (found his way into the room). It doesn't seem to like that, especially when the system is running a Software RAID. |
|
| Back to top |
|
|
idella4
Retired Dev
Joined: 09 Jun 2006
Posts: 1600
Location: Australia, Perth
|
| Posted: Sat Apr 23, 2011 3:34 pm Post subject: |
|
|
[quote="Simba7"] | idella4 wrote: | Simba7,
I guess he's been unplugging it and plugging it back in when his mom's doing other things . |
hmm that would do it..
_________________
idella4@aus |
|
| Back to top |
|
|
Letharion
Veteran
Joined: 13 Jun 2005
Posts: 1344
Location: Sweden
|
| Posted: Sun May 08, 2011 10:52 am Post subject: |
|
|
I have a raid 1 on two drives, and now I would like to install grub2 onto that drive. Grub warns me however that:
| Quote: | | /sbin/grub-setup: error: hd1 appears to contain a btrfs filesystem which isn't known to reserve space for DOS-style boot. Installing GRUB there could result in FILESYSTEM DESTRUCTION if valuable data is overwritten by grub-setup (--skip-fs-probe disables this check, use at your own risk). |
This bug over on launchpad https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/757446 indicates that btrfs does however reserve the necessary space. Before I risk it (there's nothing terribly important on there) it would be nice to hear if someone else has experience with grub2 on a btrfs partition. |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Mon May 23, 2011 1:36 pm Post subject: |
|
|
Hi there,
I've read the whole thread now and this nice thread so far.
Until now I'm using Reiser4 with lzo-compression on my root partition for several years now. Even though I had a lot of hard resets I 've never had any data loss with Reiser4. Unfortunately there seems to be a bigger problem of Reiser4 with Kernel-2.6.38. Therefore I'm getting caught with 2.6.37 and looking for a new filesystem for my root partition. I would like to have something similar to Reiser4.
Is btrfs with 2.6.39 in a usable and stable state? I've read something about an unacceptable fragmentation. What's the point there? |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Mon May 23, 2011 2:10 pm Post subject: |
|
|
Fragmentation is an issue that hits you with COW Filesystems (Copy On Write); Btrfs is still under heavy development, but I am running it as my rootfs since quite some time without any bigger problems.
Just keep away of -rc kernels and any strange patches and I'd say it's safe as long as you're on a single disk.
_________________
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 01, 2011 9:58 pm Post subject: |
|
|
The rc branch for the 3.0 kernel includes an "auto defragmentation" patch.
I'm testing it now, although I don't recommend everyone go out and try the 3.0 rc branch (heck the 2.6.39 stable branch is having enough issues).
If the fragmentation issues are solved, the next big remaining issue will probably be a working fsck tool.
Then, give it a year or two of feature stability, and Btrfs will almost be ready. |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Wed Jun 08, 2011 9:57 am Post subject: |
|
|
Testing 3.0-rc2 here with btrfs.
Compared to 2.6.39 things are looking good except for a memleak somewhere.
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
py-ro
Veteran
Joined: 24 Sep 2002
Posts: 1734
Location: Velbert
|
| Posted: Wed Jun 08, 2011 10:15 am Post subject: Re: Booting to a btrfs raid? |
|
|
| Letharion wrote: | I put in two new drives, then
| Code: | mkfs.btrfs -m raid1 -d raid1 /dev/sdb /dev/sdc
mount /dev/sdb /mnt/gentoo |
and copied my / to /mnt/gentoo. Now I'm trying to boot up on this. Grub and the kernel is still on my older drive, so that part works well, but when I try to pass of /dev/sd{b,c} as root devices to the kernel it complains that the root device cannot be mounted. My current root is btrfs as well, so I know the kernel can handle it, but my raid setup probably requires something more to work. I'm somewhat surprised I can't find it mentioned on google how to do this |
Indeed, the Kernel does no devicescan. If you use a btrfs-raid as /, you need a initramfs which does the scan.
Py |
|
| Back to top |
|
|
Veldrin
Veteran
Joined: 27 Jul 2004
Posts: 1945
Location: Zurich, Switzerland
|
| Posted: Wed Jun 08, 2011 10:40 am Post subject: |
|
|
or you define the devices inside the option - i.e rootflags=device=/dev/sdb,device=/dev/sdc
AFAIK, this procedure is described on the btrfs wiki - but I am unable to get to the page.
V.
_________________
read the portage output!
If my answer is too concise, ask for an explanation. |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Wed Jun 08, 2011 2:21 pm Post subject: |
|
|
| ToeiRei wrote: | Testing 3.0-rc2 here with btrfs.
Compared to 2.6.39 things are looking good except for a memleak somewhere. |
Forget that - I got a problem with a process writing to a non-existant file. So stuff grows without a trace.
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
Veldrin
Veteran
Joined: 27 Jul 2004
Posts: 1945
Location: Zurich, Switzerland
|
| Posted: Tue Jun 28, 2011 7:36 pm Post subject: |
|
|
Anybody having issues with btrfs raid1 setup, by using sync between the 2 disks/partitions?
This is now the third time within a mount, the fist 2 a possibly caused by unclean shutdown, but I am unsure about the this one (not even sure if it is related, apart that I am unable to boot). I recently switched to 3.0_rc4 from 2.6.39-hardened.
The first issue was resolved by rolling back a 2 week old backup  , the second by running splitting the raid1 and readding the removed disk/partition. Now with the third incident, I was able to scan/mount the devices normally an I am currently running a btrfs filesystem balance over it.
I there anything else I could do? (apart from poking the guys in ML.)
As it is my primary system, I do not want to spend to much time troubleshooting, and more just get i back up and running.
V.
_________________
read the portage output!
If my answer is too concise, ask for an explanation. |
|
| Back to top |
|
|
|
Gentoo Chat
