Re: no space left on device
Sorry for the HTML replies.. I just read the mail delivery failure and turned it to plain text. You can check the quoted text for my answers. On Fri, Jul 30, 2010 at 3:26 PM, Leonidas Spyropoulos wrote: > I use the latest btrfs-tools and 2.6.34-020634-generic kernel for lucid. > Got no issues like that, is it happening with 2.6.34 kernel as well? > > On Fri, Jul 30, 2010 at 1:27 PM, Lubos Kolouch > wrote: >> >> Yes, I pulled today's btrfs-progs. >> >> Lubos >> >> On Pá, čec 30, 2010, 13:03:10, Leonidas Spyropoulos wrote: >> > Have you updated with latest btrfs-tools? >> > >> > On Fri, Jul 30, 2010 at 6:31 AM, Lubos Kolouch >> > wrote: >> > >> > > Hello, >> > > >> > > kerner 2.6.35-rc6 >> > > >> > > btrfs filesystem df /home >> > > Data: total=1.68TB, used=987.62GB >> > > Metadata: total=56.01GB, used=48.16GB >> > > System: total=12.00MB, used=200.00KB >> > > >> > > touch: cannot touch `/home/x': No space left on device >> > > >> > > Any ideas what I should do? >> > > >> > > Thank you >> > > >> > > Lubos >> > > >> > > -- >> > > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" >> > > in >> > > the body of a message to majord...@vger.kernel.org >> > > More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > >> > >> > >> > >> > -- >> > Caution: breathing may be hazardous to your health. > > > > -- > Caution: breathing may be hazardous to your health. > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: synchronous removal?
I think a cron job checking the output of df could do that. The shell script will check if there is enough space to create a snapshot otherwise remove a snapshot. How about that? On Sun, Aug 1, 2010 at 10:11 PM, K. Richard Pixley wrote: > I have an application where I want to snapshot, then do something, and > based on the result, snapshot either the result or the previous state and > then repeat. > > So far, so good. But eventually my disk fills and I want to remove the > oldest snapshots, as many as I need to in order to make room enough for the > next cycle. > > I notice that when I remove old snapshots and delete old directories, the > free space on my disk, (according to df), doesn't rise immediately. But > instead, I see an active btrfs_cleaner for a while and my free space rises > while it runs. I'm presuming that the removed files and snapshots aren't > fully reclaimed immediately but rather wait for something akin to a garbage > collection much the way modern berkeley file systems do. > > How can I either: > > a) wait for the cleaner to digest the free space > b) determine that the cleaner has digested all available free space for now, > (if not I can sleep for a while) > c) synchronously force the cleaner to digest available free space > d) something else I haven't thought of yet > > Basically, I want to check to see if there's enough space available. If > not, I want to remove some things, (including at least one snapshot), wait > for the cleaner to digest, and then start over with the checking to see if > there's enough space available and loop until I've removed enough things > that there is enough space available. How can I do that on a btrfs file > system? > > --rich > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Raid0 with btrfs
Hi all, I want to make a btrfs raid0 on 2 partitions of my pc. Until now I am using the mdadm tools to make a software raid of the 2 partitions /dev/sde2, /dev/sdd2 and then mkfs.etx4 the newly created /dev/md0 device. >From performance point of view is it better to keep the configuration of mdadm and just format the /dev/md0 device as btrfs OR delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 as a btrfs with 2 devices? mkfs.btrfs /dev/sde2 /dev/sdd2 On a sidenote: If I decide to go for raid5 which is not supported currently from mkfs I have to use the mdadm tool anyway, right? -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raid0 with btrfs
Do I have to change the partition ID flag of each partition? Currently is set to fd (Linux Raid autodetect) for used from mdadm mkfs.btrfs supports that or needs to be 83 (Linux) ? On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario wrote: > On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: >> Hi all, >> >> I want to make a btrfs raid0 on 2 partitions of my pc. >> Until now I am using the mdadm tools to make a software raid of the 2 >> partitions /dev/sde2, /dev/sdd2 >> and then mkfs.etx4 the newly created /dev/md0 device. >> From performance point of view is it better to keep the configuration of >> mdadm and just format the /dev/md0 device as btrfs OR >> delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 >> as a btrfs with 2 devices? >> mkfs.btrfs /dev/sde2 /dev/sdd2 > > Btrfs already supports metadata mirroring when the data is striped. What this > means, is while the performance should be more-or-less identical to MD RAID0 > (if it isn't it's a bug), your data is a bit more secure as the metadata > describing it resides on both drives. Later on it will be possible to selct > which directories/files should have what level of redundancy. This will allow > to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories > on the same partition and filesystem. > >> On a sidenote: >> If I decide to go for raid5 which is not supported currently from mkfs >> I have to use the mdadm tool anyway, right? > > yes, RAID5 code is not in trunk yet. > > -- > Hubert Kario > QBS - Quality Business Software > 02-656 Warszawa, ul. Ksawerów 30/85 > tel. +48 (22) 646-61-51, 646-74-24 > www.qbs.com.pl > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raid0 with btrfs
On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen wrote: > On 6 August 2010 20:23, Leonidas Spyropoulos wrote: >> Do I have to change the partition ID flag of each partition? >> Currently is set to fd (Linux Raid autodetect) for used from mdadm >> mkfs.btrfs supports that or needs to be 83 (Linux) ? > > FD is for mdraid integrated into the Linux kernel. I have mine at 83. > It won't hurt to have them at FD, but the kernel will spend extra time > as it probes the devices on boot, causing a slight slowdown. Ok done them id 83 and used 3 devices eventually Using raid0 for data and metadata # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 2 SATA and 1 ATA drive I thought that ATA will bottleneck the other 2 drives but seems like I gain something from it. Using iozone for benchmark: # iozone -s 8g -r 1024 -i 0 -i 1 with 2 SATA devices and then 3 devices (SATA + ATA): KB reclen write rewrite read reread 83886081024 134869 139607 229146 228800 83886081024 135151 139050 233461 235929 The above is with -o compress option enabled and my cpu topped up on 100% cpu (both cores) while test and copy huge data. Is it possible I am bottlenecked by my cpu speed? AMD Opteron 165 @ 2700 Mhz >> >> On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario wrote: >>> On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: >>>> Hi all, >>>> >>>> I want to make a btrfs raid0 on 2 partitions of my pc. >>>> Until now I am using the mdadm tools to make a software raid of the 2 >>>> partitions /dev/sde2, /dev/sdd2 >>>> and then mkfs.etx4 the newly created /dev/md0 device. >>>> From performance point of view is it better to keep the configuration of >>>> mdadm and just format the /dev/md0 device as btrfs OR >>>> delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 >>>> as a btrfs with 2 devices? >>>> mkfs.btrfs /dev/sde2 /dev/sdd2 >>> >>> Btrfs already supports metadata mirroring when the data is striped. What >>> this >>> means, is while the performance should be more-or-less identical to MD RAID0 >>> (if it isn't it's a bug), your data is a bit more secure as the metadata >>> describing it resides on both drives. Later on it will be possible to selct >>> which directories/files should have what level of redundancy. This will >>> allow >>> to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both directories >>> on the same partition and filesystem. >>> >>>> On a sidenote: >>>> If I decide to go for raid5 which is not supported currently from mkfs >>>> I have to use the mdadm tool anyway, right? >>> >>> yes, RAID5 code is not in trunk yet. >>> >>> -- >>> Hubert Kario >>> QBS - Quality Business Software >>> 02-656 Warszawa, ul. Ksawerów 30/85 >>> tel. +48 (22) 646-61-51, 646-74-24 >>> www.qbs.com.pl >>> >> >> >> >> -- >> Caution: breathing may be hazardous to your health. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > Regards, > Sebastian J. > > PS. Please try to bottom-post rather than top-post. Here's a link I > can advise reading for a clarification on why bottom posting is > essential: http://www.caliburn.nl/topposting.html > Thanks for the heads up about bottom-posting. -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raid0 with btrfs
On Sat, Aug 7, 2010 at 1:03 AM, Sebastian 'gonX' Jensen wrote: > On 7 August 2010 00:24, Leonidas Spyropoulos wrote: >> On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen >> wrote: >>> On 6 August 2010 20:23, Leonidas Spyropoulos wrote: >>>> Do I have to change the partition ID flag of each partition? >>>> Currently is set to fd (Linux Raid autodetect) for used from mdadm >>>> mkfs.btrfs supports that or needs to be 83 (Linux) ? >>> >>> FD is for mdraid integrated into the Linux kernel. I have mine at 83. >>> It won't hurt to have them at FD, but the kernel will spend extra time >>> as it probes the devices on boot, causing a slight slowdown. >> >> Ok done them id 83 and used 3 devices eventually >> Using raid0 for data and metadata >> # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 >> >> 2 SATA and 1 ATA drive >> I thought that ATA will bottleneck the other 2 drives but seems like I gain >> something from it. >> Using iozone for benchmark: >> # iozone -s 8g -r 1024 -i 0 -i 1 >> with 2 SATA devices and then 3 devices (SATA + ATA): >> KB reclen write rewrite read reread >> 8388608 1024 134869 139607 229146 228800 >> 8388608 1024 135151 139050 233461 235929 >> >> The above is with -o compress option enabled and my cpu topped up on >> 100% cpu (both cores) while test and copy huge data. >> Is it possible I am bottlenecked by my cpu speed? >> AMD Opteron 165 @ 2700 Mhz >> >>>> >>>> On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario wrote: >>>>> On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: >>>>>> Hi all, >>>>>> >>>>>> I want to make a btrfs raid0 on 2 partitions of my pc. >>>>>> Until now I am using the mdadm tools to make a software raid of the 2 >>>>>> partitions /dev/sde2, /dev/sdd2 >>>>>> and then mkfs.etx4 the newly created /dev/md0 device. >>>>>> From performance point of view is it better to keep the configuration of >>>>>> mdadm and just format the /dev/md0 device as btrfs OR >>>>>> delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 >>>>>> as a btrfs with 2 devices? >>>>>> mkfs.btrfs /dev/sde2 /dev/sdd2 >>>>> >>>>> Btrfs already supports metadata mirroring when the data is striped. What >>>>> this >>>>> means, is while the performance should be more-or-less identical to MD >>>>> RAID0 >>>>> (if it isn't it's a bug), your data is a bit more secure as the metadata >>>>> describing it resides on both drives. Later on it will be possible to >>>>> selct >>>>> which directories/files should have what level of redundancy. This will >>>>> allow >>>>> to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both >>>>> directories >>>>> on the same partition and filesystem. >>>>> >>>>>> On a sidenote: >>>>>> If I decide to go for raid5 which is not supported currently from mkfs >>>>>> I have to use the mdadm tool anyway, right? >>>>> >>>>> yes, RAID5 code is not in trunk yet. >>>>> >>>>> -- >>>>> Hubert Kario >>>>> QBS - Quality Business Software >>>>> 02-656 Warszawa, ul. Ksawerów 30/85 >>>>> tel. +48 (22) 646-61-51, 646-74-24 >>>>> www.qbs.com.pl >>>>> >>>> >>>> >>>> >>>> -- >>>> Caution: breathing may be hazardous to your health. >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>>> the body of a message to majord...@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> Regards, >>> Sebastian J. >>> >>> PS. Please try to bottom-post rather than top-post. Here's a link I >>> can advise reading for a clarification on why bottom posting is >>> essential: http://www.caliburn.nl/topposting.html >>> >> Thanks for the heads up about bottom-posting. >> >> >> -- >> Caution: breathing may be hazardous to your health. >> > > It seems odd that you are reaching 100% CPU usage. Maybe it's because &
Re: Raid0 with btrfs
On Sat, Aug 7, 2010 at 12:16 PM, Leonidas Spyropoulos wrote: > On Sat, Aug 7, 2010 at 1:03 AM, Sebastian 'gonX' Jensen > wrote: >> On 7 August 2010 00:24, Leonidas Spyropoulos wrote: >>> On Fri, Aug 6, 2010 at 7:32 PM, Sebastian 'gonX' Jensen >>> wrote: >>>> On 6 August 2010 20:23, Leonidas Spyropoulos wrote: >>>>> Do I have to change the partition ID flag of each partition? >>>>> Currently is set to fd (Linux Raid autodetect) for used from mdadm >>>>> mkfs.btrfs supports that or needs to be 83 (Linux) ? >>>> >>>> FD is for mdraid integrated into the Linux kernel. I have mine at 83. >>>> It won't hurt to have them at FD, but the kernel will spend extra time >>>> as it probes the devices on boot, causing a slight slowdown. >>> >>> Ok done them id 83 and used 3 devices eventually >>> Using raid0 for data and metadata >>> # mkfs.btrfs -m raid0 -d raid0 /dev/sdc1 /dev/sdd2 /dev/sde2 >>> >>> 2 SATA and 1 ATA drive >>> I thought that ATA will bottleneck the other 2 drives but seems like I gain >>> something from it. >>> Using iozone for benchmark: >>> # iozone -s 8g -r 1024 -i 0 -i 1 >>> with 2 SATA devices and then 3 devices (SATA + ATA): >>> KB reclen write rewrite read reread >>> 8388608 1024 134869 139607 229146 228800 >>> 8388608 1024 135151 139050 233461 235929 >>> >>> The above is with -o compress option enabled and my cpu topped up on >>> 100% cpu (both cores) while test and copy huge data. >>> Is it possible I am bottlenecked by my cpu speed? >>> AMD Opteron 165 @ 2700 Mhz >>> >>>>> >>>>> On Thu, Aug 5, 2010 at 3:40 PM, Hubert Kario wrote: >>>>>> On Thursday 05 August 2010 16:15:22 Leonidas Spyropoulos wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I want to make a btrfs raid0 on 2 partitions of my pc. >>>>>>> Until now I am using the mdadm tools to make a software raid of the 2 >>>>>>> partitions /dev/sde2, /dev/sdd2 >>>>>>> and then mkfs.etx4 the newly created /dev/md0 device. >>>>>>> From performance point of view is it better to keep the configuration of >>>>>>> mdadm and just format the /dev/md0 device as btrfs OR >>>>>>> delete the raid device and format the 2 partitions /dev/sde2 /dev/sdd2 >>>>>>> as a btrfs with 2 devices? >>>>>>> mkfs.btrfs /dev/sde2 /dev/sdd2 >>>>>> >>>>>> Btrfs already supports metadata mirroring when the data is striped. What >>>>>> this >>>>>> means, is while the performance should be more-or-less identical to MD >>>>>> RAID0 >>>>>> (if it isn't it's a bug), your data is a bit more secure as the metadata >>>>>> describing it resides on both drives. Later on it will be possible to >>>>>> selct >>>>>> which directories/files should have what level of redundancy. This will >>>>>> allow >>>>>> to have ~/work RAID1-ed and ~/videos RAID0-ed while keeping both >>>>>> directories >>>>>> on the same partition and filesystem. >>>>>> >>>>>>> On a sidenote: >>>>>>> If I decide to go for raid5 which is not supported currently from mkfs >>>>>>> I have to use the mdadm tool anyway, right? >>>>>> >>>>>> yes, RAID5 code is not in trunk yet. >>>>>> >>>>>> -- >>>>>> Hubert Kario >>>>>> QBS - Quality Business Software >>>>>> 02-656 Warszawa, ul. Ksawerów 30/85 >>>>>> tel. +48 (22) 646-61-51, 646-74-24 >>>>>> www.qbs.com.pl >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Caution: breathing may be hazardous to your health. >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>>>> the body of a message to majord...@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >>>> >>>> Regards, >>>> Sebastian J. >>>> >>>> PS. Please try to bottom-post rather than top-post
Re: Poor creat/delete files performance
Have you tried umounting and mounting before the second test to eliminate any caching? Which kernel you use? 2010/8/18 Miao Xie : > Hi, > > We did some performance test and found the create/delete files performance > of btrfs is very poor. > > The test is that we create 5 files and measure the file-create time > first, and then delete these 5 files and measure the file-delete time. > (The attached file is the reproduce program) > > The result is following: > (Unit: second) > Create file performance > BtrFS Ext4 > Total times: 2.462625 1.449550 > Average: 0.49 0.29 > > Delete file performance > BtrFS Ext4 > Total times: 3.312796 0.997946 > Average: 0.66 0.20 > > The results were measured on a x86_64 server with 4 cores and 2 SAS disks. > By debuging, we found the btrfs spent a lot of time on searching and > inserting/removing items in the ctree. > > Is anyone looking at this issue? > > Regards > Miao Xie > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs filesystem df not working
The above command is not working on my system. Information: btrfs f df /media/data Btrfs v0.19-35-g1b444cd Linux woofy 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux mount info: /dev/sdd2 on /media/data type btrfs (rw,noexec,nosuid,nodev) /media/data is a raid 0 filesystem $ btrfs filesystem show failed to read /dev/sr0 Label: none uuid: 1882b025-58e4-4287-98a3-9b772af0ad76 Total devices 2 FS bytes used 72.56GB devid2 size 74.53GB used 54.01GB path /dev/sdd2 devid3 size 74.53GB used 54.01GB path /dev/sde2 Any ideas? This is on an testing/unstable Debian system. -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs filesystem df not working
On Tue, Oct 12, 2010 at 2:43 PM, cwillu wrote: > On Tue, Oct 12, 2010 at 4:12 AM, Leonidas Spyropoulos > wrote: >> The above command is not working on my system. >> Information: >> btrfs f df /media/data > > btrfs f isn't unique; fi is the minimum to specify "filesystem" > I tried even with btrfs filesystem df /media/data and same results. -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs filesystem df not working
On Wed, Oct 13, 2010 at 1:43 AM, Chris Mason wrote:
> On Tue, Oct 12, 2010 at 02:45:19PM +0100, Leonidas Spyropoulos wrote:
>> On Tue, Oct 12, 2010 at 2:43 PM, cwillu wrote:
>> > On Tue, Oct 12, 2010 at 4:12 AM, Leonidas Spyropoulos
>> > wrote:
>> >> The above command is not working on my system.
>> >> Information:
>> >> btrfs f df /media/data
>> >
>> > btrfs f isn't unique; fi is the minimum to specify "filesystem"
>> >
>> I tried even with btrfs filesystem df /media/data
>> and same results.
>
> Does strace give us any clues?
>
According to strace there is inappropriate ioctl for the device.
Here is the log
PS: results are the same for root access
[ing...@woofy ~]$ strace btrfs filesystem df /media/data/
execve("/usr/local/bin/btrfs", ["btrfs", "filesystem", "df",
"/media/data/"], [/* 16 vars */]) = 0
brk(0) = 0x11ed000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fd28d424000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=126024, ...}) = 0
mmap(NULL, 126024, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd28d405000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libuuid.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\25\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=15720, ...}) = 0
mmap(NULL, 2110736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fd28d005000
mprotect(0x7fd28d009000, 2093056, PROT_NONE) = 0
mmap(0x7fd28d208000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fd28d208000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\355\1\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1432968, ...}) = 0
mmap(NULL, 3541032, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fd28cca4000
mprotect(0x7fd28cdfc000, 2093056, PROT_NONE) = 0
mmap(0x7fd28cffb000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x157000) = 0x7fd28cffb000
mmap(0x7fd28d00, 18472, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd28d00
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fd28d404000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fd28d402000
arch_prctl(ARCH_SET_FS, 0x7fd28d402740) = 0
mprotect(0x7fd28cffb000, 16384, PROT_READ) = 0
mprotect(0x7fd28d426000, 4096, PROT_READ) = 0
munmap(0x7fd28d405000, 126024) = 0
brk(0) = 0x11ed000
brk(0x120e000) = 0x120e000
stat("/media/data/", {st_mode=S_IFDIR|0755, st_size=124, ...}) = 0
open("/media/data/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
ioctl(3, 0xc0109414, 0x11f5620) = -1 ENOTTY (Inappropriate
ioctl for device)
> -chris
>
>
--
Caution: breathing may be hazardous to your health.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs filesystem df not working
On Wed, Oct 13, 2010 at 4:08 PM, Chris Mason wrote: > On Wed, Oct 13, 2010 at 10:52:57AM +0100, Leonidas Spyropoulos wrote: >> On Wed, Oct 13, 2010 at 1:43 AM, Chris Mason wrote: >> > On Tue, Oct 12, 2010 at 02:45:19PM +0100, Leonidas Spyropoulos wrote: >> >> On Tue, Oct 12, 2010 at 2:43 PM, cwillu wrote: >> >> > On Tue, Oct 12, 2010 at 4:12 AM, Leonidas Spyropoulos >> >> > wrote: >> >> >> The above command is not working on my system. >> >> >> Information: >> >> >> btrfs f df /media/data >> >> > >> >> > btrfs f isn't unique; fi is the minimum to specify "filesystem" >> >> > >> >> I tried even with btrfs filesystem df /media/data >> >> and same results. >> > >> > Does strace give us any clues? >> > >> According to strace there is inappropriate ioctl for the device. >> Here is the log > > I missed this before: > > 2.6.32-5-amd64 > > The df ioctl was added after 2.6.32 (2.6.33 I think). So in debian squeeze/unstable which is currently on 2.6.32 (and won't change any sooner) I cannot use btrfs. All I can do is try experimental kernels? My question though is, if I use experimental kernels can I then load an "old" kernel and still use the btrfs filesystem? Or the newer kernels write anything specials on ionodes which the old ones cannot read? > > -chris > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs filesystem df not working
On Thu, Oct 14, 2010 at 5:42 PM, Chris Mason wrote: > On Thu, Oct 14, 2010 at 12:45:59PM +0100, Leonidas Spyropoulos wrote: >> On Wed, Oct 13, 2010 at 4:08 PM, Chris Mason wrote: >> > On Wed, Oct 13, 2010 at 10:52:57AM +0100, Leonidas Spyropoulos wrote: >> >> On Wed, Oct 13, 2010 at 1:43 AM, Chris Mason >> >> wrote: >> >> > On Tue, Oct 12, 2010 at 02:45:19PM +0100, Leonidas Spyropoulos wrote: >> >> >> On Tue, Oct 12, 2010 at 2:43 PM, cwillu wrote: >> >> >> > On Tue, Oct 12, 2010 at 4:12 AM, Leonidas Spyropoulos >> >> >> > wrote: >> >> >> >> The above command is not working on my system. >> >> >> >> Information: >> >> >> >> btrfs f df /media/data >> >> >> > >> >> >> > btrfs f isn't unique; fi is the minimum to specify "filesystem" >> >> >> > >> >> >> I tried even with btrfs filesystem df /media/data >> >> >> and same results. >> >> > >> >> > Does strace give us any clues? >> >> > >> >> According to strace there is inappropriate ioctl for the device. >> >> Here is the log >> > >> > I missed this before: >> > >> > 2.6.32-5-amd64 >> > >> > The df ioctl was added after 2.6.32 (2.6.33 I think). >> >> So in debian squeeze/unstable which is currently on 2.6.32 (and won't >> change any sooner) I cannot use btrfs. All I can do is try >> experimental kernels? > > Or backport the changes, yes. Sorry, I don't understand what "backport the changes" means? > >> My question though is, if I use experimental kernels can I then load >> an "old" kernel and still use the btrfs filesystem? >> Or the newer kernels write anything specials on ionodes which the old >> ones cannot read? > > We haven't made any of those changes, you'll be fine going back and > forth. > > -chris > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Backporting Recent Btrfs Patches to 2.6.32
On Fri, Oct 15, 2010 at 8:23 PM, Mitch Harder wrote: > Since the 2.6.32 kernel is one of the long-term stable kernels, and > since a few projects (such as OpenVZ) and distros (such as Debian) are > using the 2.6.32 kernel, I've put together an experimental git branch > to backport later btrfs patches to the 2.6.32 kernel. > > Let me know if there's any interest in this experiment, and I'll try > to keep it maintained. > > I've placed a git repository containing this work here: > > http://gitweb.sabayon.org/?p=linux/kernel/btrfs-backport.git;a=summary > > The backport is currently in "works-for-me" status, and I have been > using it for about a week without crashes. > > I did not attempt to backport every patch that has touched > linux/fs/btrfs compared to the 2.6.32 kernel. Some patches were part > of larger kernel updates that would be outside the scope of a > backport. > > I was able to backport the DIO patches and the improvements to ENOSPC > handling, as well as most of the other patches in the btrfs-unstable > repository. > > Let me know if you have any feedback. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi there, I've been trying to install your kernel into my debian squezze/sid system for test the new features of btrfs with failure so far. My problem is that I have a 2.6.32 kernel and recent changes affecting the btrfs system is not implemented so your repo seems like a life-savior. The only thing is that I am not able to fetch it. I always stuck to fatal: The remote end hung up unexpectedly Also I wouldn't mind updating the kernel to newer ones although I am not able to find any repositories with .deb files for 2.6.32 and above. The only choise so far is experimental 2.6.36 repo which seems to work but I don't have the linux-kbuild for installing the headers. Thus the idea of building one myself. Any suggestion of how to get the new changes of btrfs on my linux-box would be welcome. Thanks Leonidas PS: sorry if this is kinda out of the mailing-list topics. -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs filesystem defragment error
While on Ubuntu 10.10 I cannot get defragment working. ing...@selene:~$ btrfs filesystem defragment /media/Data/ ioctl failed on /media/Data/ ret -1 errno 1 total 1 failures ing...@selene:~$ uname -a Linux selene 2.6.35-23-generic #36-Ubuntu SMP Tue Oct 26 17:03:18 UTC 2010 i686 GNU/Linux ing...@selene:~$ sudo btrfs filesystem show [sudo] password for inglor: failed to read /dev/sr0 Label: 'Data' uuid: 3946b7c3-44c8-430e-b737-0c0c965e16c4 Total devices 1 FS bytes used 12.32GB devid1 size 29.08GB used 28.75GB path /dev/sda7 Btrfs v0.19-35-g1b444cd Is it implemented on kernel 2.6.36 and above only? -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mount problem
Hey all, I have a weird error with my RAID 0 btrfs partition. Information for the partitions follow: # btrfs filesystem show failed to read /dev/sr0 Label: none uuid: 1882b025-58e4-4287-98a3-9b772af0ad76 Total devices 2 FS bytes used 108.16GB devid2 size 74.53GB used 55.26GB path /dev/sdd2 devid3 size 74.53GB used 55.26GB path /dev/sde2 Btrfs v0.19-35-g1b444cd # btrfs device scan Scanning for Btrfs filesystems failed to read /dev/sr0 # cat /etc/fstab | grep btrfs /dev/disk/by-uuid/1882b025-58e4-4287-98a3-9b772af0ad76 /media/data btrfs rw,user 0 0 # blkid /dev/sdd2: UUID="1882b025-58e4-4287-98a3-9b772af0ad76" UUID_SUB="468b49fa-a0b6-4e11-a312-ef0cafd2890a" TYPE="btrfs" /dev/sde2: UUID="1882b025-58e4-4287-98a3-9b772af0ad76" UUID_SUB="cf534558-a317-4259-808b-d950a155fb5d" TYPE="btrfs" Although I have the config within fstab it doesn't mount on bootup with error: mount: wrong fs type, bad option, bad superblock on /dev/sde2, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Kernel messages: device fsid 8742e45825b08218-76adf02a779ba398 devid 3 transid 4778 /dev/sde2 btrfs: failed to read the system array on sde2 No matter how many times I try with sudo mount -a or sudo mount /media/data I got the same error. Now the weird stuff: If I do a blkid and fdisk -l I can then mount normally the partition. Any ideas? Kernel info: Linux woofy 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 Dual Core AMD Opteron(tm) Processor 165 AuthenticAMD GNU/Linux btrfs-progs: Latest from git I don't know which revision/patch Arch stock kernel has of btrfs. Thanks, Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mount problem
2011/1/12 Tsutomu Itoh : > (2011/01/12 9:25), Leonidas Spyropoulos wrote: >> Hey all, >> >> I have a weird error with my RAID 0 btrfs partition. >> Information for the partitions follow: >> >> # btrfs filesystem show >> failed to read /dev/sr0 >> Label: none uuid: 1882b025-58e4-4287-98a3-9b772af0ad76 >> Total devices 2 FS bytes used 108.16GB >> devid 2 size 74.53GB used 55.26GB path /dev/sdd2 >> devid 3 size 74.53GB used 55.26GB path /dev/sde2 >> >> Btrfs v0.19-35-g1b444cd >> >> # btrfs device scan >> Scanning for Btrfs filesystems >> failed to read /dev/sr0 >> >> # cat /etc/fstab | grep btrfs >> /dev/disk/by-uuid/1882b025-58e4-4287-98a3-9b772af0ad76 /media/data >> btrfs rw,user 0 0 >> >> # blkid >> /dev/sdd2: UUID="1882b025-58e4-4287-98a3-9b772af0ad76" >> UUID_SUB="468b49fa-a0b6-4e11-a312-ef0cafd2890a" TYPE="btrfs" >> /dev/sde2: UUID="1882b025-58e4-4287-98a3-9b772af0ad76" >> UUID_SUB="cf534558-a317-4259-808b-d950a155fb5d" TYPE="btrfs" >> >> Although I have the config within fstab it doesn't mount on bootup with >> error: >> mount: wrong fs type, bad option, bad superblock on /dev/sde2, >> missing codepage or helper program, or other error >> In some cases useful info is found in syslog - try >> dmesg | tail or so >> >> Kernel messages: >> device fsid 8742e45825b08218-76adf02a779ba398 devid 3 transid 4778 /dev/sde2 >> btrfs: failed to read the system array on sde2 > > Please see Problem_FAQ in btrfs wiki. > (https://btrfs.wiki.kernel.org/index.php/Problem_FAQ) > > Thanks, > Itoh > >> >> No matter how many times I try with sudo mount -a or sudo mount >> /media/data I got the same error. >> >> Now the weird stuff: >> If I do a blkid and fdisk -l I can then mount normally the partition. >> Any ideas? >> >> Kernel info: Linux woofy 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 >> CET 2011 x86_64 Dual Core AMD Opteron(tm) Processor 165 AuthenticAMD >> GNU/Linux >> btrfs-progs: Latest from git >> I don't know which revision/patch Arch stock kernel has of btrfs. >> >> >> Thanks, >> Leonidas >> > > Hey cwillu and Itoh, Thanks both for the answers, so as I can see I have 2 options: Either find the startup scripts of Arch Linux and run the scan command before parsing fstab (this should be in /etc/rc.conf ?) OR edit fstab with parameters the correct devices like: /dev/disk/by-uuid/1882b025-58e4-4287-98a3-9b772af0ad76 /media/data btrfs device=/dev/sde2,device=/dev/sdd2,rw,user 0 0 I think though that the devices names are randomly chosen in startup from udev, right? (this is the reason I use uuids) so effectivly i have just an option. Thanks, Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mount problem
On 12 January 2011 00:58, Leonidas Spyropoulos wrote: > 2011/1/12 Tsutomu Itoh : >> (2011/01/12 9:25), Leonidas Spyropoulos wrote: >>> Hey all, >>> >>> I have a weird error with my RAID 0 btrfs partition. >>> Information for the partitions follow: >>> >>> # btrfs filesystem show >>> failed to read /dev/sr0 >>> Label: none uuid: 1882b025-58e4-4287-98a3-9b772af0ad76 >>> Total devices 2 FS bytes used 108.16GB >>> devid 2 size 74.53GB used 55.26GB path /dev/sdd2 >>> devid 3 size 74.53GB used 55.26GB path /dev/sde2 >>> >>> Btrfs v0.19-35-g1b444cd >>> >>> # btrfs device scan >>> Scanning for Btrfs filesystems >>> failed to read /dev/sr0 >>> >>> # cat /etc/fstab | grep btrfs >>> /dev/disk/by-uuid/1882b025-58e4-4287-98a3-9b772af0ad76 /media/data >>> btrfs rw,user 0 0 >>> >>> # blkid >>> /dev/sdd2: UUID="1882b025-58e4-4287-98a3-9b772af0ad76" >>> UUID_SUB="468b49fa-a0b6-4e11-a312-ef0cafd2890a" TYPE="btrfs" >>> /dev/sde2: UUID="1882b025-58e4-4287-98a3-9b772af0ad76" >>> UUID_SUB="cf534558-a317-4259-808b-d950a155fb5d" TYPE="btrfs" >>> >>> Although I have the config within fstab it doesn't mount on bootup with >>> error: >>> mount: wrong fs type, bad option, bad superblock on /dev/sde2, >>> missing codepage or helper program, or other error >>> In some cases useful info is found in syslog - try >>> dmesg | tail or so >>> >>> Kernel messages: >>> device fsid 8742e45825b08218-76adf02a779ba398 devid 3 transid 4778 /dev/sde2 >>> btrfs: failed to read the system array on sde2 >> >> Please see Problem_FAQ in btrfs wiki. >> (https://btrfs.wiki.kernel.org/index.php/Problem_FAQ) >> >> Thanks, >> Itoh >> >>> >>> No matter how many times I try with sudo mount -a or sudo mount >>> /media/data I got the same error. >>> >>> Now the weird stuff: >>> If I do a blkid and fdisk -l I can then mount normally the partition. >>> Any ideas? >>> >>> Kernel info: Linux woofy 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 >>> CET 2011 x86_64 Dual Core AMD Opteron(tm) Processor 165 AuthenticAMD >>> GNU/Linux >>> btrfs-progs: Latest from git >>> I don't know which revision/patch Arch stock kernel has of btrfs. >>> >>> >>> Thanks, >>> Leonidas >>> >> >> > > Hey cwillu and Itoh, > > Thanks both for the answers, so as I can see I have 2 options: > Either find the startup scripts of Arch Linux and run the scan command > before parsing fstab (this should be in /etc/rc.conf ?) > OR > edit fstab with parameters the correct devices like: > /dev/disk/by-uuid/1882b025-58e4-4287-98a3-9b772af0ad76 /media/data > btrfs device=/dev/sde2,device=/dev/sdd2,rw,user 0 0 > > I think though that the devices names are randomly chosen in startup > from udev, right? > (this is the reason I use uuids) > so effectivly i have just an option. > > Thanks, > Leonidas > > -- > Caution: breathing may be hazardous to your health. > I searched around and after consulting with #archlinux irc channel the best way to do that is to add a hook in mkinitcpio. This tool already has a btrfs hook current version so simply add it before filesystem hook and recreate the initramfs For my stock kernel: mkinitcpio -p kernel26 Worked fine. Thanks Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'ioctl:: Inappropriate ioctl for device' when trying to shrink partition
On 12 January 2011 18:45, Mikael Andersson wrote: > E.g. btrfsctl -r -4000m /dev/sda5 > Hey Mikael, btrfsctl is deprecated, you should use btrfs In the previous example: btrfs filesystem resize -4000m /dev/sda5 Check the help of btrfs And also good to download latest btrfs-progs from git and compile them yourself the version of btrfs-progs on LiveCD is old. Latest version I use for example is: v0.19-35-g1b444cd > results in: > ioctl:: Inappropriate ioctl for device > > Distribution: Ubuntu 10.10 > Kernel: 2.6.35-22-generic > > According to the Synaptic Package manager, the version of btrfs-tools is > 0.19+20100601-3 > > Other information that can be of interest: > - I started Ubuntu on a live CD > - before invoking the btrfsctl command I invoked apt-get update. > > I have googled but have not found anything that seems to help me. > > I have searched for "resize" on the following pages but have not find > anything: > https://btrfs.wiki.kernel.org/index.php/Problem_FAQ > https://btrfs.wiki.kernel.org/index.php/Gotchas > > Thanks, > > Mikael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Recommended settings for SSD
Hello list,
I just got myself a new SSD and decided to install yet another time
btrfs with ubuntu 13.04. I would like to ask if you suggest anything
for recommended options for mount on Crucial S4 SSD.
At the moment I am using:
defaults,noatime,nodiratime,ssd,subvol=@home
Anything else someone recommends for performance, stability?
Thanks in advance
Leonidas
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommended settings for SSD
On 24 May 2013 21:07, "cwillu" wrote: > > No need to specify ssd, it's automatically detected. I'm not so sure it did detected. When I manually set it I saw significant improvement. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommended settings for SSD
On Sat, May 25, 2013 at 4:58 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Without going back to check the wiki, IIRC it was there that the /sys
> paths it checks for that detection are listed. Those paths are then
> based on what the drive itself claims. If it claims to be rotating
> storage...
I remember reading something like that myself, maybe my SSD (Crucial
S4) is old enough to report rotating storage, don't know..
>
> It may also depend on the kernel version, etc, as I'm not sure when that
> auto-detection was added (tho for all I know it has been there awhile).
>
> I do know my new SSDs (Corsair Neutrons, 256GB) are detected here, and
> the ssd mount option is thus not needed. However, I'm running current
> v3.10-rcX-git kernels, tho I'm a few days behind ATM as I'm still working
> on switching over to the SSDs ATM and am having to do some reconfiguring
> to get there.
>
> Btrfs still being marked for testing only and under heavy development, if
> people aren't at least running current Linus stable or better and don't
> have a specific bug as a reason not to, they're actually behind and are
> likely missing potentially critical patches. That means most people
> trying to run btrfs on stock distro kernels will be behind...
>
I agree on that, it could be related, my kernel version is stock
3.8.0-22-generic (getting sources now to recompile latest)
>
> Meanwhile, what about the discard option? As I'm still setting up on the
> SSDs as well as btrfs here, I haven't had a chance to decide whether I
> want that, or would rather setup fstrim as a cron job, or what. But
> that's the other big question for SSD.
>
I decided not to add the discard option and run the daily script from
cron (fstrim) as I think there's a performance hit with the discard.
It mainly depends on your hardware I think.
> Here, I'm actually partitioning for near 100% over-provisioning, (120-ish
> GiB of partitions on the 238GiB/256GB drives, so I suspect actually
> running with discard as a mount option won't be such a big deal and will
> likely only cut write performance as I head toward stable-state, since
> the drive should have plenty of trimmed space to work with in any case
> due to the over-provisioning. But I suspect it could be of benefit to
> those much closer to 0% over-provisioning than to my near 100%.
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Since I am going to build the kernel and it's a good test on the SSD
does anyone recommend some ways to speed up the build related to SSD?
Thanks
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommended settings for SSD
On Sat, May 25, 2013 at 1:13 PM, Martin Steigerwald wrote:
> Am Samstag, 25. Mai 2013, 03:58:12 schrieb Duncan:
> [...]
> And can be verified by:
>
> martin@merkaba:~> grep ssd /proc/mounts
> /dev/mapper/merkaba-debian / btrfs rw,noatime,compress=lzo,ssd,space_cache 0 0
> /dev/mapper/merkaba-debian /mnt/debian-zeit btrfs
> rw,noatime,compress=lzo,ssd,space_cache 0 0
> /dev/mapper/merkaba-home /home btrfs rw,noatime,compress=lzo,ssd,space_cache 0
> 0
> /dev/mapper/merkaba-home /mnt/home-zeit btrfs
> rw,noatime,compress=lzo,ssd,space_cache 0 0
> martin@merkaba:~> grep ssd /etc/fstab
> martin@merkaba:~#1>
> [...]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I see you are using compression. I don't have compression at the
moment and I would like to use it. What will happen to the data that
are already on the partitions? Will it be compressed when I use them?
Do I have to re-write them? Would it be compressed with btrfs defrag
command?
Thanks for the information
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommended settings for SSD
On Sat, May 25, 2013 at 11:33 PM, Harald Glatt wrote:
> Data that already exists will only be compressed on re-write. You can
> do it with btrfs fi defrag and a script that traverses the fs to call
> defrag on every file. Another good way is the find command that has
> been outlined here:
>
> https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#Defragmenting_a_directory_doesn.27t_work
>
I tried to my home partition the 'find' command and worked without
errors, not sure if it did compress (how can I check?). I tried also
on the root partition and every file that was in use (obviously) it
didn't defrag it. I am guessing I have to mount the partition from a
LiveCD but since the LiceCD kernel is usually old (in terms of btrfs)
do you reckon there will be any problems?
Thanks
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Slow mounting raid1
Hello, I got a raid1 setup of btrfs on a HDD array of 2 disks. The fstab has the following mount settings: # cat /etc/fstab | grep raid1 UUID=c9db91e6-0ba8-4ae6-b471-8fd4ff7ee72d /media/raid1 btrfs rw,relatime,compress=lzo,space_cache 0 0 When I try to mount the array it's consistent about 5 seconds+ # time umount /media/raid1 real0m0.358s user0m0.010s sys 0m0.010s # time mount /media/raid1 real0m5.605s user0m0.504s sys 0m0.071s I have this setup for sometime now and from the time I made it the mount time went up (I notice that on boot). When I first build that was almost instant. In terms of maintenance I regularly run a scrub and rebalance every now and then. Running kernel 4.11.12 (with -ck patchs) Is there something I can do to speed it up (apart buying 2 SSDs :D ). I feel like I'm missing something as the usage of the raid is not really frequent - just backup mainly. Thanks for your time. -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow mounting raid1
Load_Cycle_Count0x0012 093 093 000Old_age Always - 8407 194 Temperature_Celsius 0x0002 166 166 000Old_age Always - 36 (Min/Max 17/64) 196 Reallocated_Event_Count 0x0032 100 100 000Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x000a 200 200 000Old_age Always - 0 > 1) Attempting to mount filesystems with many devices is of course > slower. But two devices shouldn't be a problem. > > 2) Sometimes a device might take awhile to "spin up" and initialize > itself. Since you're still on spinning rust, are the devices perhaps > spinning down to save power, and the delay you see is them spinning back > up? > Good idea but even when I do it like below it's still 6 seconds: # time umount /media/raid1 && time mount /media/raid1 real0m0.501s user0m0.046s sys 0m0.011s real0m5.540s user0m0.943s sys 0m0.062s > SSDs may have a similar, tho generally shorter and for different reasons, > delay. SSDs often have a capacitor that charges up so they can finish a > write and avoid corrupting themselves in the event of an unexpected power > loss in the middle of a write. A lower end device might allow the device > to appear ready while the capacitor is still charging to avoid long power- > on response times, while higher end devices both tend to have higher > capacity capacitors, and don't signify ready until they are sufficiently > charged to avoid issues in "blink" situations where the power supply > comes back on but isn't immediately steady and might go out again right > away. > > If a device takes too long and times out you'll see resets and the like > in dmesg, but that normally starts at ~30 seconds, not the 5 seconds you > mention. Still, doesn't hurt to check. Nothing on dmesg related as you can see. > > 3) If the space cache is damaged the mount may take longer, but btrfs > will complain so you'll see it in dmesg. > That was my idea and that's why I asked in ML. I'll give 'noatime' a go and see if it's changes anything. -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow mounting raid1
On 01/08/17, E V wrote: > In general I think btrfs takes time proportional to the size of your > metadata to mount. Bigger and/or fragmented metadata leads to longer > mount times. My big backup fs with >300GB of metadata takes over > 20minutes to mount, and that's with the space tree which is > significantly faster then space cache v1. > Hmm my raid1 doesn't seem near to full or has a significant Metadata so I don't I'm on this case: # btrfs fi show /media/raid1/ Label: 'raid1' uuid: c9db91e6-0ba8-4ae6-b471-8fd4ff7ee72d Total devices 2 FS bytes used 516.18GiB devid1 size 931.51GiB used 518.03GiB path /dev/sdd devid2 size 931.51GiB used 518.03GiB path /dev/sde # btrfs fi df /media/raid1/ Data, RAID1: total=513.00GiB, used=512.21GiB System, RAID1: total=32.00MiB, used=112.00KiB Metadata, RAID1: total=5.00GiB, used=3.97GiB GlobalReserve, single: total=512.00MiB, used=0.00B I tried the space_cache=v2 just to see if it would do any difference but nothing changed # cat /etc/fstab | grep raid1 UUID=c9db91e6-0ba8-4ae6-b471-8fd4ff7ee72d /media/raid1 btrfs rw,noatime,compress=lzo,space_cache=v2 0 0 # time umount /media/raid1 && time mount /media/raid1/ real0m0.807s user0m0.237s sys 0m0.441s real0m5.494s user0m0.618s sys 0m0.116s I did a couple of rebalances on metadata and data and it improved a bit: # btrfs balance start -musage=100 /media/raid1/ # btrfs balance start -dusage=10 /media/raid1/ [.. incremental dusage 10 -> 95] # btrfs balance start -dusage=95 /media/raid1 Down to 3.7 sec # time umount /media/raid1 && time mount /media/raid1/ real0m0.807s user0m0.237s sys 0m0.441s real0m3.790s user0m0.430s sys 0m0.031s I think maybe the next step is to disable compression if I want to mount it faster. Is this normal for BTRFS that performance would degrade after some time? Regards, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID5 doesn't mount on boot, but you can afterwards?
Hello, On 30/09/15, Sjoerd wrote: > Hi All, > > A RAID5 setup on raw devices doesn't want to automount on boot. > [..] Post your /etc/fstab file please. Thanks -- Sent using mutt -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unable to open ctree
Hi all, I'm a everyday user of btrfs. The system is a laptop with UEFI partition and the following partition scheme: # blkid /dev/sda1: UUID="." TYPE="vfat" PARTUUID="." /dev/sda2: UUID="." TYPE="swap" PARTUUID="." /dev/sda3: LABEL="root" UUID="." UUID_SUB="." TYPE="btrfs" PARTUUID="." /dev/sda4: LABEL="home" UUID="." UUID_SUB="." TYPE="btrfs" PARTUUID="." The partitions are surely not out of space: # btrfs fi show Label: 'root' uuid: c7a773e0-e2be-4482-acdc-dbfa4c13c98c Total devices 1 FS bytes used 9.98GiB devid1 size 74.52GiB used 13.03GiB path /dev/sda3 Label: 'home' uuid: 63f5219f-399a-4cce-be86-a8c7400853bd Total devices 1 FS bytes used 17.65GiB devid1 size 188.87GiB used 25.03GiB path /dev/sda4 When the "root" partition is to be mounted during boot up it fails and I am dropped on an emergency shell. The dmesg output is: [ 716.434137] BTRFS info (device sda3): disk space caching is enabled [ 716.434147] BTRFS info (device sda3): has skinny extents [ 716.436538] BTRFS info (device sda3): bdev /dev/sda3 errs: wr 0, rd 0, flush 0, corrupt 32, gen 0 [ 716.439182] BTRFS warning (device sda3): sda3 checksum verify failed on 11185160192 wanted 2670F0AB found FDB2F5BD level 0 [ 716.439195] BTRFS error (device sda3): failed to read block groups: -5 [ 716.481402] BTRFS: open_ctree failed The btrfs check /dev/sdc3 output is https://ptpb.pw/nc1d dmesg output: https://ptpb.pw/G0Wv The kernel I was running is right before this failure was 4.7.5 (with ck patchset custom compiled) and there was not any kernel panics - just a restart. Currently runnign through latest Archlinux liveCD # uname -a Linux archiso 4.7.5-1-ARCH #1 SMP PREEMPT Sat Sep 24 13:04:22 CEST 2016 x86_64 GNU/Linux # btrfs --version btrfs-progs v4.7.3 As this is the root partition I am not able to access it without a liveCD. Can I perform any kind of steps to recaclulate checksums? Thanks -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to open ctree
Hi Chris, Thanks for your suggestions On 02/10/16, Chris Murphy wrote: > Well short of a bug, the problem aren't the checksums. The problem is > the metadata is wrong, so if you recalculate checksums you're likely > end up with an even more corrupted file system because it'll start out > trusting bad metadata. > > If you're prepared to lose this filesystem, use --repair and see if it > can fix the metadata problems despite csum failures. If it were me, > I'd take a btrfs-image before --repair. In theory, if it makes things > worse you can restore the image, or donate the image to making the > btrfsck better. > > If --repair doesn't work, try -b --repair. > > If that doesn't work then I'd probably use --init-extent-tree which, > while it's a heavy hammer, at least still isn't going to pretend bad > metadata is good which is what --init-csum-tree will end up doing. > > But before all of that I'm curious what you get for: > > btrfs-debug-tree -b 11185160192 /dev/sda3 > btrfs-find-root /dev/sda3 The output from btrfs-debug-tree command is: https://ptpb.pw/0weU The btrfs-find-root: https://ptpb.pw/PIZe The btrfs-show-super -f : https://ptpb.pw/O4C9 I tried the btrfs-image but failed # btrfs-image /dev/sda3 /root/sda3-btrfs-image.bin with output https://ptpb.pw/jtDJ Unless there's some other idea I will continue with the following: # btrfs check --repair # btrfs check -b --repair # btrfs check --init-extent-tree --repair and see if I can get something Thanks, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to open ctree
Hi Roman, On 03/10/16, Roman Mamedov wrote: > On Sun, 2 Oct 2016 13:29:56 -0600 > Chris Murphy wrote: > > > Well short of a bug, the problem aren't the checksums. The problem is > > the metadata is wrong, so if you recalculate checksums you're likely > > end up with an even more corrupted file system because it'll start out > > trusting bad metadata. > > It appears that metadata got created with profile "single", because the device > is SSD. If this was DUP metadata, this entire problem wouldn't happen. > It is a terrible idea to downgrade metadata to single on detecting SSDs at > mkfs. The original rationale was that "SSDs will deduplicate it anyways", but > there are many ways things can corrupt way before reaching the SSD (from the > point of view of which it will look like the computer sent two different > metadata blocks, if one got corrupted in flight), and secondly, the ability of > SSDs to perfectly deduplicate small 4K sized pieces of data at hundreds of > megabytes in read/write speeds is VASTLY overestimated here. I agree that the wear in SSDs due to metadata dublications is overestimated and since my partition appears to be screwed I will make sure next time to force it to have another copy there. My progress from the repairs which both failed are: https://ptpb.pw/CtbC Next step is initialize the extent tree btrfs check --init-extent-tree --repair /dev/sda3 Thanks, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to open ctree
Hello, After the command to rebuild the extent tree # btrfs check --init-extent-tree --repair /dev/sda3 I was able to mount and run successfully a scrub (not sure if it would detect something though). Next was reboot and try to boot which was successful as well. I'll keep an eye on the dmesh log next days but seems it's ok. Thanks for suggestions all, Regards, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: performance recommendations
Hi Laszlo, On 16/02/21, Pal, Laszlo wrote: > Hi, > > Thank you. So, I've installed a new centos7 with the same > configuration, old kernel and using btrfs. Then, upgraded the kernel > to 5.11 and all went well, so I thought let's do it on the prod server > Since this is a VM can you clone the disk / partition and attach it to another VM which running a newer kernel and btrfs progs? This way you can try debugging it without affecting prod server. > Unfortunately when I boot on 5.11 sysroot mount times out and I have > something like this in log > > btrfs open ctree failed So before that `dmesg` doesn't have any relevant logs? > > Any quick fix for this? I'm able to mount btrfs volume using a rescuCD > but I have the same issues, like rm a big file takes 10 minutes If you manage to mount the disk in a newer kernel and btrfs progs try creating a new file system to take advantage of the new feature (on creation) - then migrate the data and follow the recommendations mentioned already. Cheers, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
"No space left on device"
Hello, I've been following this list for years and I see during various situations this message coming up. Some times it's a genuine problem that there is actually not enough space. In other cases it's some by-product of something else. I have seen this error personality on a broken system ( which I never figured out what had happened). I know this is still experimental but I just want to make sure my expectations are not really out on sync with the others. As an end user when I see an error like this the first thing I will do is check the space (using 'df' command) [1]. If I see more that 7% I usually think it's OK, (depends on the size of partition as well). - Is this unreasonable in btrfs filesystem? Is there a formula to calculate how much space btrfs _might_ need? - It's probably not your job but can df reports correct sizes for btrfs? I've seen some threads on trying to show the actual space occupied by data and/or metadata with btrfs command. Can we expect this someone to be incorporated into df command? - In cases that btrfs reports this error but there's something else that's causing it, can we expect better error handling from btrfs so the end user is pointed to the correct direction? [1]: one could argue that an end user should use the btrfs commands instead but let's leave that for now. Apologies if these have already been answered or are already on roadmap. Thanks in advanced, your comments are appreciated. Kind regards, Leonidas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs balance on single device
Hey all,
Just did a btrfs balance on a single device. Before the balance
operation here is the df result:
inglor@tiamat ~$ btrfs fi df /home
Data: total=19.19GB, used=9.34GB
System, DUP: total=32.00MB, used=4.00KB
Metadata, DUP: total=896.00MB, used=227.98MB
Then I issues a balance operation relocating the chunks across a single device:
inglor@tiamat ~$ sudo btrfs fi balance /home
[sudo] password for inglor:
Done, had to relocate 28 out of 28 chunks
After I did another df:
inglor@tiamat ~$ btrfs fi df /home
Data: total=10.00GB, used=9.34GB
System, DUP: total=32.00MB, used=4.00KB
Metadata, DUP: total=384.00MB, used=226.80MB
Anyone can explain me the Data row of the above output ? It used to be
19.19GB and now it's 10.00GB. It's like the partition shrunk!? The
balance operation finished without issues.
Here's some other information:
inglor@tiamat ~$ sudo btrfs filesystem show
Label: 'home' uuid: 458c70e2-7037-4c4d-bba2-3d5288f04510
Total devices 1 FS bytes used 9.56GB
devid1 size 21.00GB used 10.81GB path /dev/sda3
Label: none uuid: 699d671b-7064-441d-95ec-c616049fe287
Total devices 1 FS bytes used 13.94GB
devid1 size 20.00GB used 20.00GB path /dev/sda2
Btrfs v0.20-rc1-358-g194aa4a-dirty
inglor@tiamat ~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 20971520 15362816 3960288 80% /
/dev/sda3 22020096 10256168 11375416 48% /home
Thanks,
Leonidas
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs balance on single device
On Sun, Dec 15, 2013 at 8:24 PM, Hugo Mills wrote:
> On Sun, Dec 15, 2013 at 08:20:19PM +0000, Leonidas Spyropoulos wrote:
>> Hey all,
[..]
>> Anyone can explain me the Data row of the above output ? It used to be
>> 19.19GB and now it's 10.00GB. It's like the partition shrunk!? The
>> balance operation finished without issues.
>
>It freed up some of the unused data chunks, returning them to the
> unallocated space on the device.
>
Oh, so the df report from btrfs doesn't show the total as 'free'! But
it means how much space the filesystem allocated so far.
>> Here's some other information:
>>
>> inglor@tiamat ~$ sudo btrfs filesystem show
>> Label: 'home' uuid: 458c70e2-7037-4c4d-bba2-3d5288f04510
>> Total devices 1 FS bytes used 9.56GB
>> devid1 size 21.00GB used 10.81GB path /dev/sda3
>
>You can see that the filesystem is still the same size as before --
> it's just that less of it is allocated.
>
>There's nothing to worry about here -- it's all working as expected.
>
>Hugo.
>
Thanks Hugo for the explanation
Leonidas
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs balance on single device
On Sun, Dec 15, 2013 at 11:28 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Leonidas Spyropoulos posted on Sun, 15 Dec 2013 20:28:05 + as
> excerpted:
>
>> Oh, so the df report from btrfs doesn't show the total as 'free'! But it
>> means how much space the filesystem allocated so far.
>
> Yes.
>
> Btrfs allocates in chunks, 256 MiB at a time for metadata (but on a
> single device, metadata chunks are DUP by default, so two are created at
> once, thus half a gig), 1 GiB at at a time for data (single device
> values, when there's plenty of unallocated space left in ordered to do
> so). As these chunks are filled up new ones are allocated as necessary
> (assuming there's enough unallocated space left to do so).
>
> But normal usage including deleting old files and rewriting parts of
> existing files (to new locations due to btrfs' copy-on-write/COW
> semantics) will often leave several partially filled chunks around, and a
> balance rewrites chunks, consolidating into fewer new chunks when
> possible as it does so.
>
> That's what the btrfs fi df reports showed, many partially filled chunks
> before the balance, fewer but full chunks afterward, with the freed chunk
> space returned to the unallocated pool.
>
> While btrfs fi df could report unallocated space as well, given the
> possibility of it being allocated differently (DUP vs SINGLE, and on
> multi-device filesystems, the various raid modes), it can't reliably
> predict how that unallocated space will be used and thus how much
> /effective/ free space you have.
>
> But btrfs fi show gives the total filesystem size, as well as the total
> allocated. So between df and show, plus a little math if necessary, you
> get a better picture.
But on the time that someone invokes the "btrfs fi df" command all the
informations are available on the underlying driver to determine the
type of allocation (DUP or SINGLE) and if the volume is single or multi
device. So is there a reason not to do the maths for the user and
present her/him with the correct information, saving her/his braincells
from maths? :)
I assume there's performance degragation from having all the chunks
allocated in a volume. Is there a recomendation on how often once should
run the balance operation? If on the other hand no performance is
decreased from having all the chunks allocated why not allocate them on
the start (creation of filesystem / mount - not sure which is
appropriate).
>
> --
> Duncan - List replies preferred. No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." Richard Stallman
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Leonidas
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs balance on single device
I'm using the same subject as it might be relevant, feel free to change it.# I'm trying to do some maintenance to the system running over a btrfs file system on root (/). I started a balance on the '/' partition and it failed with the below information: $ sudo btrfs balance start / [sudo] password for inglor: ERROR: error during balancing '/' - No space left on device There may be more info in syslog - try dmesg | tail $ dmesg | tail [93827.115887] btrfs: found 29461 extents [93827.481849] btrfs: relocating block group 29855055872 flags 1 [93841.646011] btrfs: found 33171 extents [93851.421207] btrfs: found 33171 extents [93851.782054] btrfs: relocating block group 28781314048 flags 1 [93866.815342] btrfs: found 52535 extents [93877.159354] btrfs: found 52534 extents [93877.356805] btrfs: relocating block group 28747759616 flags 34 [93880.287185] btrfs: found 1 extents [93880.608798] btrfs: 1 enospc errors during balance $ df |grep sda2 /dev/sda2 20971520 13980396 5797124 71% / $ sudo btrfs fi show [sudo] password for inglor: Label: none uuid: 699d671b-7064-441d-95ec-c616049fe287 Total devices 1 FS bytes used 12.75GB devid1 size 20.00GB used 15.31GB path /dev/sda2 Btrfs v0.20-rc1-358-g194aa4a-dirty $ sudo btrfs fi df / [sudo] password for inglor: Data: total=13.00GB, used=12.16GB System, DUP: total=32.00MB, used=4.00KB Metadata, DUP: total=1.12GB, used=601.54MB Does it really needs more than 5.7GB to do a balance? I though it suppose to move chunks one by one and considering the chunks for Data is 1GB and for MetaData 512MB (256 x2 for dublication) it should be more than enough. Also I had less space before and the dmesg reported 7 enospc errors. With cleaning a bit of packages installed now it reports only 1 enospc. Is that anywhere relevant? Thanks, Leonidas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: improve the performance fluctuating of the fsync
On Wed, Dec 18, 2013 at 06:52:44PM +0800, Miao Xie wrote: > In order to improve the performance of fsync, we use the outstanding > ordered extents to avoid looking up the checksum from the csum tree. > But we didn't filter out the ordered extents whose csum is still being > calculated, when we got those ordered extents, we had to wait for the > csum calculation. It made the performance dropped down suddenly. (On > my box, it drop down from 56MB/s to 4-10MB/s) > > But actually, the csum calculation of the ordered extents which were > introduced by the current fsync had already completed. Those ordered > extents whose csum was being calculated didn't belong to the current > fsync, we can ignore them. > > By this patch, the performance fluctuating doesn't happen, and the average > performance grows up by ~2%. > [..] Will this help with apt-get performance over btrfs file system? As far as I understand it it's happening because of multiple fsync calls. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs balance on single device
On Wed, Dec 18, 2013 at 11:05:29AM +, Hugo Mills wrote: > On Wed, Dec 18, 2013 at 10:44:43AM +0000, Leonidas Spyropoulos wrote: > > I'm using the same subject as it might be relevant, feel free to change it.# > > > > I'm trying to do some maintenance to the system running over a btrfs file > > system on root (/). I started a balance on the '/' partition and it failed > > with the below information: > > $ sudo btrfs balance start / > > [sudo] password for inglor: > > ERROR: error during balancing '/' - No space left on device > > There may be more info in syslog - try dmesg | tail > > $ dmesg | tail > > [93827.115887] btrfs: found 29461 extents > > [93827.481849] btrfs: relocating block group 29855055872 flags 1 > > [93841.646011] btrfs: found 33171 extents > > [93851.421207] btrfs: found 33171 extents > > [93851.782054] btrfs: relocating block group 28781314048 flags 1 > > [93866.815342] btrfs: found 52535 extents > > [93877.159354] btrfs: found 52534 extents > > [93877.356805] btrfs: relocating block group 28747759616 flags 34 > > [93880.287185] btrfs: found 1 extents > > [93880.608798] btrfs: 1 enospc errors during balance > >You don't specify your kernel version, but if it's older than 3.11 > or so, you should probably upgrade -- 3.10 and earlier had occasional > bugs where the block reserve system never kept enough blocks free to > add a new metadata chunk when it was needed, which led to exactly this > kind of symptom. You are right, apologies. It is an up to date Archlinux box with a kernel: $ uname -a Linux tiamat 3.12.5-1-ARCH #1 SMP PREEMPT Thu Dec 12 12:57:31 CET 2013 x86_64 GNU/Linux > >Alternatively, and this is a bit of a long shot given that the > error seems to have been while relocating your system chunk (which > argues against this particular diagnosis), but: > >Do you have a large file on that filesystem (larger than 1 GiB)? Unlikely since the btrfs file system in question is '/' exluding /opt and /media directories (these are other partitions) $ sudo find / -type f -size +1048576k -and -not -path "/media*" -print /proc/kcore find: `/proc/27221/task/27221/fd/5': No such file or directory find: `/proc/27221/task/27221/fdinfo/5': No such file or directory find: `/proc/27221/fd/5': No such file or directory find: `/proc/27221/fdinfo/5': No such file or directory find: `/run/user/1000/gvfs': Permission denied inglor@tiamat ~$ > >If so, I would recommend switching to a 3.12 kernel, and running a > defrag on the file. There's a known and now-fixed bug where you can > get ENOSPC while balancing, if a file has an extent larger than 1 GiB > in size. (The bug being that there's an extent over 1 GiB in size in > the first place). I might try the defrag option anyway and restart the balance operation, see if this will help anyway. Thanks, Leonidas > >Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- I'd make a joke about UDP, but I don't know if --- > anyone's actually listening... -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs balance on single device
On Wed, Dec 18, 2013 at 11:29 AM, Leonidas Spyropoulos
wrote:
> On Wed, Dec 18, 2013 at 11:05:29AM +, Hugo Mills wrote:
>> On Wed, Dec 18, 2013 at 10:44:43AM +, Leonidas Spyropoulos wrote:
>> > I'm using the same subject as it might be relevant, feel free to change
>> > it.#
>> >
>> > I'm trying to do some maintenance to the system running over a btrfs file
>> > system on root (/). I started a balance on the '/' partition and it failed
>> > with the below information:
>> > $ sudo btrfs balance start /
>> > [sudo] password for inglor:
>> > ERROR: error during balancing '/' - No space left on device
>> > There may be more info in syslog - try dmesg | tail
>> > $ dmesg | tail
>> > [93827.115887] btrfs: found 29461 extents
>> > [93827.481849] btrfs: relocating block group 29855055872 flags 1
>> > [93841.646011] btrfs: found 33171 extents
>> > [93851.421207] btrfs: found 33171 extents
>> > [93851.782054] btrfs: relocating block group 28781314048 flags 1
>> > [93866.815342] btrfs: found 52535 extents
>> > [93877.159354] btrfs: found 52534 extents
>> > [93877.356805] btrfs: relocating block group 28747759616 flags 34
>> > [93880.287185] btrfs: found 1 extents
>> > [93880.608798] btrfs: 1 enospc errors during balance
>>
>>You don't specify your kernel version, but if it's older than 3.11
>> or so, you should probably upgrade -- 3.10 and earlier had occasional
>> bugs where the block reserve system never kept enough blocks free to
>> add a new metadata chunk when it was needed, which led to exactly this
>> kind of symptom.
>
> You are right, apologies. It is an up to date Archlinux box with a kernel:
> $ uname -a
> Linux tiamat 3.12.5-1-ARCH #1 SMP PREEMPT Thu Dec 12 12:57:31 CET 2013 x86_64
> GNU/Linux
>
>>
>>Alternatively, and this is a bit of a long shot given that the
>> error seems to have been while relocating your system chunk (which
>> argues against this particular diagnosis), but:
>>
>>Do you have a large file on that filesystem (larger than 1 GiB)?
>
> Unlikely since the btrfs file system in question is '/' exluding /opt and
> /media directories (these are other partitions)
> $ sudo find / -type f -size +1048576k -and -not -path "/media*" -print
> /proc/kcore
> find: `/proc/27221/task/27221/fd/5': No such file or directory
> find: `/proc/27221/task/27221/fdinfo/5': No such file or directory
> find: `/proc/27221/fd/5': No such file or directory
> find: `/proc/27221/fdinfo/5': No such file or directory
> find: `/run/user/1000/gvfs': Permission denied
> inglor@tiamat ~$
>
>>
>>If so, I would recommend switching to a 3.12 kernel, and running a
>> defrag on the file. There's a known and now-fixed bug where you can
>> get ENOSPC while balancing, if a file has an extent larger than 1 GiB
>> in size. (The bug being that there's an extent over 1 GiB in size in
>> the first place).
>
> I might try the defrag option anyway and restart the balance operation, see
> if this will help anyway.
Some progress on this. I managed to do a balance on data only. The
problem seems to be happening when doing a metadata balance
$ sudo btrfs balance start -m /
[sudo] password for inglor:
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
$ dmesg | tail
[171492.384314] systemd-journald[183]: Deleted empty journal
/var/log/journal/64cfb6f6c9d1625e7fa463c20475/user-120@8b61bc353813451babcaa25dfc82c64e--.journal
(2924544 bytes).
[171492.384375] systemd-journald[183]: Vacuuming done, freed 2924544 bytes
[172242.011051] btrfs: relocating block group 109781712896 flags 36
[172242.075298] btrfs: relocating block group 109748158464 flags 34
[172242.286016] btrfs: found 1 extents
[172242.419286] btrfs: 1 enospc errors during balance
Is there a way to recreate the metadata? (I'm guessing the answer is balance..)
>
> Thanks,
> Leonidas
>
>>
>>Hugo.
>>
>> --
>> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>> PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>> --- I'd make a joke about UDP, but I don't know if ---
>> anyone's actually listening...
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
no space left on device
Hey all, I run into no space left on device on a virtualbox After installing Debian 6 on a virtual machine I tried installing the KDE desktop The system HDD is 8Gb Both root (/) and /home are btrfs over LVM. While installing the packages I run into: no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total df shows only 74% used space on / kernel used: stock debian 6 2.6.32-5-686 At the moment I cannot access it with normal boot, only recovery mode. I can provide whatever info you would like as long as you think of a way to load the normal system and not the recovery mode. -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no space left on device
On Feb 8, 2011 12:09 AM, "C Anthony Risinger" wrote: > > On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos > wrote: > > Hey all, > > > > I run into no space left on device on a virtualbox > > > > After installing Debian 6 on a virtual machine > > I tried installing the KDE desktop > > > > The system HDD is 8Gb > > Both root (/) and /home are btrfs > > over LVM. > > > > While installing the packages I run into: > > > > no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0 > > bytes_reserved, > > 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total > > > > df shows only 74% used space on / > > > > kernel used: stock debian 6 2.6.32-5-686 > > > > At the moment I cannot access it with normal boot, only recovery mode. > > > > I can provide whatever info you would like as long as you think of a > > way to load the normal system and not the recovery mode. > > IIRC .32 has all sorts of ENOSPC problems; I think this was seriously > tackled in kernels > .32... this kernel was only declared ready for > "early adopters", with an "expect issues" disclaimer. > > The btrfs-tools in squeeze is probably so old you may not even have > the `btrfs` binary, but I don't run debian so I'm not sure there... > not really a solution probably for you, but I wouldn't run that kernel > if using btrfs. > > C Anthony Hey all, Thanks for all the answers. The problem is that I cannot login to the system.only recovery mode works, and there btrfs command is not there as you imagined. I will try though ssh but I don't think it's installed by default and I cannot install it. So the next step is try from recovery console of debian live cd, which still has the really old tools... I think this is quite some serious issue but generally all debian's fault adopting a btrfs file system support on a 2.6.32 kernel and without btrfs-progs on some decent version. I'll update when possible. Please throw any other alternatives my way anyone. Thanks, Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no space left on device
On 8 February 2011 09:31, cwillu wrote: > On Tue, Feb 8, 2011 at 3:00 AM, Leonidas Spyropoulos > wrote: >> On Feb 8, 2011 12:09 AM, "C Anthony Risinger" wrote: >>> >>> On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos >>> wrote: >>> > Hey all, >>> > >>> > I run into no space left on device on a virtualbox >>> > >>> > After installing Debian 6 on a virtual machine >>> > I tried installing the KDE desktop >>> > >>> > The system HDD is 8Gb >>> > Both root (/) and /home are btrfs >>> > over LVM. >>> > >>> > While installing the packages I run into: >>> > >>> > no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0 >>> > bytes_reserved, >>> > 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total >>> > >>> > df shows only 74% used space on / >>> > >>> > kernel used: stock debian 6 2.6.32-5-686 >>> > >>> > At the moment I cannot access it with normal boot, only recovery mode. >>> > >>> > I can provide whatever info you would like as long as you think of a >>> > way to load the normal system and not the recovery mode. >>> >>> IIRC .32 has all sorts of ENOSPC problems; I think this was seriously >>> tackled in kernels > .32... this kernel was only declared ready for >>> "early adopters", with an "expect issues" disclaimer. >>> >>> The btrfs-tools in squeeze is probably so old you may not even have >>> the `btrfs` binary, but I don't run debian so I'm not sure there... >>> not really a solution probably for you, but I wouldn't run that kernel >>> if using btrfs. >>> >>> C Anthony >> >> Hey all, >> >> Thanks for all the answers. >> >> The problem is that I cannot login to the system.only recovery mode works, >> and there btrfs command is not there as you imagined. >> >> I will try though ssh but I don't think it's installed by default and I >> cannot install it. >> >> So the next step is try from recovery console of debian live cd, which still >> has the really old tools... >> >> I think this is quite some serious issue but generally all debian's fault >> adopting a btrfs file system support on a 2.6.32 kernel and without >> btrfs-progs on some decent version. >> >> I'll update when possible. >> Please throw any other alternatives my way anyone. > > I have to be blunt, blaming your problems on debian isn't terribly > classy. The ", shiny!" reflex is your fault, not debian's. Well you are right it is my problem and yeah I wanted to test the "new shiny" Debian 6 with officially btrfs supported. For the moment I apt-get clean to get some space since my / was updating the KDE (so it had a lot of cache files there) Reserved something like 300Mb and then vlextend the / But the next step is to update kernel and btrfs-progs from git. Thanks for answers > > Download and install a prebuilt 2.6.35 or later kernel into your /boot > via a livecd or whatever, unpack and add the btrfs command to the > initramfs for that kernel, boot up into that initramfs with the kernel > option "break=premount", and fix the rootfs from the busybox prompt. The above seems unknown to me. Could you elaborate a bit please? > > Alternatively, an ubuntu natty alpha livecd has a 2.6.38 kernel, and > you can install mostly up-to-date btrfs tools into that environment. > I'm sure debian has something similar available. I was wondering how to fix this without liveCD. > > --Carey Underwood > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TRIM support
Hello, I just installed an archlinux with btrfs root partition and would like to set the correct mount properties Following this: https://wiki.archlinux.org/index.php/Solid_State_Drives it says there that I should use the discard mount parameter to enable TRIM. I would like to ask by using ssd mount parameter would TRIM be enabled? The SSD is Intel 320 Series 120Gb Thanks Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TRIM support
On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos wrote: > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton > wrote: >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >>> Hello, >>> >>> I just installed an archlinux with btrfs root partition and would like >>> to set the correct mount properties >>> Following this: >>> https://wiki.archlinux.org/index.php/Solid_State_Drives >>> it says there that I should use the discard mount parameter to enable TRIM. >>> >>> I would like to ask by using ssd mount parameter would TRIM be enabled? >>> The SSD is Intel 320 Series 120Gb >> >> No, the "ssd" mount parameter has nothing to do with TRIM. >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where >> the default setting is designed to improve performance on spinning HDD, >> and instead tunes for the random-access ability of an SSD. >> >> The ssd option is automatically enabled if the kernel detects that your >> drive is an SSD (you can check with 'cat /proc/mounts'). >> >> The discard option is not currently automatically enabled; I think there >> may have been some performance issues in certain cases with drives that >> have slow trim implementations. But feel free to give it a try. >> >> -- >> Calvin Walton >> >> On the same system when I try to compile the btrfs-tools I get an error. Since on the wiki you mention only the packages for Fedora and Debian, Which are the requirements for the btrfs tools? PS: AUR package is broken as well. -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TRIM support
On Sun, Jul 3, 2011 at 1:20 PM, Hubert Kario wrote: > On Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote: >> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos >> >> wrote: >> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton > wrote: >> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >> >>> Hello, >> >>> >> >>> I just installed an archlinux with btrfs root partition and would like >> >>> to set the correct mount properties >> >>> Following this: >> >>> https://wiki.archlinux.org/index.php/Solid_State_Drives >> >>> it says there that I should use the discard mount parameter to enable >> >>> TRIM. >> >>> >> >>> I would like to ask by using ssd mount parameter would TRIM be enabled? >> >>> The SSD is Intel 320 Series 120Gb >> >> >> >> No, the "ssd" mount parameter has nothing to do with TRIM. >> >> >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where >> >> the default setting is designed to improve performance on spinning HDD, >> >> and instead tunes for the random-access ability of an SSD. >> >> >> >> The ssd option is automatically enabled if the kernel detects that your >> >> drive is an SSD (you can check with 'cat /proc/mounts'). >> >> >> >> The discard option is not currently automatically enabled; I think there >> >> may have been some performance issues in certain cases with drives that >> >> have slow trim implementations. But feel free to give it a try. >> >> >> >> -- >> >> Calvin Walton >> >> On the same system when I try to compile the btrfs-tools I get an error. >> Since on the wiki you mention only the packages for Fedora and Debian, >> >> Which are the requirements for the btrfs tools? >> >> PS: AUR package is broken as well. > > the AUR package is OK, problem is that the sources don't compile with new gcc. > > Download Hugo's integration branch > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630 I download the files: git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630 > and apply my patch to it: > http://www.spinics.net/lists/linux-btrfs/msg10965.html Then I tried to apply the patch you mentioned: patch < rem.diff but it's failing: The rem.diff is the file attached > -- > Hubert Kario > QBS - Quality Business Software > 02-656 Warszawa, ul. Ksawerów 30/85 > tel. +48 (22) 646-61-51, 646-74-24 > www.qbs.com.pl > Here is the error I am getting: patching file mkfs.c Hunk #1 FAILED at 1060. Hunk #2 FAILED at 1070. 2 out of 2 hunks FAILED -- saving rejects to file mkfs.c.rej patching file volumes.c Hunk #1 FAILED at 868. Hunk #2 FAILED at 920. 2 out of 2 hunks FAILED -- saving rejects to file volumes.c.rej I think the file I created is wrong. What is the accepted format for the patch command? -- Caution: breathing may be hazardous to your health. mkfs.c|3 --- volumes.c |2 -- 2 files changed, 0 insertions(+), 5 deletions(-) diff --git a/mkfs.c b/mkfs.c index 1b5ef06..d40b2e8 100644 --- a/mkfs.c +++ b/mkfs.c @@ -1060,7 +1060,6 @@ static int make_image(char *source_dir, struct btrfs_root *root, int out_fd) struct btrfs_trans_handle *trans; struct stat root_st; - int root_len; struct directory_name_entry dir_head; @@ -1070,8 +1069,6 @@ static int make_image(char *source_dir, struct btrfs_root *root, int out_fd) goto fail; } - root_len = strlen(source_dir); - INIT_LIST_HEAD(&dir_head.list); trans = btrfs_start_transaction(root, 1); diff --git a/volumes.c b/volumes.c index 61af845..95c2e0d 100644 --- a/volumes.c +++ b/volumes.c @@ -868,7 +868,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handle *trans, struct list_head *dev_list = &extent_root->fs_info->fs_devices->devices; struct list_head *cur; struct map_lookup *map; - u64 physical; u64 calc_size = 8 * 1024 * 1024; int num_stripes = 1; int sub_stripes = 0; @@ -920,7 +919,6 @@ int btrfs_alloc_data_chunk(struct btrfs_trans_handle *trans, btrfs_set_stack_stripe_devid(stripe, device->devid); btrfs_set_stack_stripe_offset(stripe, dev_offset); memcpy(stripe->dev_uuid, device->uuid, BTRFS_UUID_SIZE); - physical = dev_offset; index++; }
Fwd: TRIM support
On Sun, Jul 3, 2011 at 3:54 PM, Hubert Kario wrote: > On Sunday 03 of July 2011 14:56:40 Leonidas Spyropoulos wrote: >> On Sun, Jul 3, 2011 at 1:20 PM, Hubert Kario wrote: >> > On Sunday 03 of July 2011 00:40:46 Leonidas Spyropoulos wrote: >> >> On Sat, Jul 2, 2011 at 11:39 PM, Leonidas Spyropoulos >> >> >> >> wrote: >> >> > On Sat, Jul 2, 2011 at 8:45 PM, Calvin Walton >> >> > >> > >> > wrote: >> >> >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >> >> >>> Hello, >> >> >>> >> >> >>> I just installed an archlinux with btrfs root partition and would >> >> >>> like to set the correct mount properties >> >> >>> Following this: >> >> >>> https://wiki.archlinux.org/index.php/Solid_State_Drives >> >> >>> it says there that I should use the discard mount parameter to >> >> >>> enable TRIM. >> >> >>> >> >> >>> I would like to ask by using ssd mount parameter would TRIM be >> >> >>> enabled? The SSD is Intel 320 Series 120Gb >> >> >> >> >> >> No, the "ssd" mount parameter has nothing to do with TRIM. >> >> >> >> >> >> The "ssd" mount parameter adjusts a couple of tuning parameters where >> >> >> the default setting is designed to improve performance on spinning >> >> >> HDD, and instead tunes for the random-access ability of an SSD. >> >> >> >> >> >> The ssd option is automatically enabled if the kernel detects that >> >> >> your drive is an SSD (you can check with 'cat /proc/mounts'). >> >> >> >> >> >> The discard option is not currently automatically enabled; I think >> >> >> there may have been some performance issues in certain cases with >> >> >> drives that have slow trim implementations. But feel free to give it >> >> >> a try. >> >> >> >> >> >> -- >> >> >> Calvin Walton >> >> >> >> On the same system when I try to compile the btrfs-tools I get an error. >> >> Since on the wiki you mention only the packages for Fedora and Debian, >> >> >> >> Which are the requirements for the btrfs tools? >> >> >> >> PS: AUR package is broken as well. >> > >> > the AUR package is OK, problem is that the sources don't compile with new >> > gcc. >> > >> > Download Hugo's integration branch >> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ >> > integration-20110630 >> >> I download the files: >> >> git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ >> integration-20110630 >> >> > and apply my patch to it: >> > http://www.spinics.net/lists/linux-btrfs/msg10965.html >> >> Then I tried to apply the patch you mentioned: >> >> patch < rem.diff >> >> but it's failing: >> The rem.diff is the file attached >> >> > -- >> > Hubert Kario >> > QBS - Quality Business Software >> > 02-656 Warszawa, ul. Ksawerów 30/85 >> > tel. +48 (22) 646-61-51, 646-74-24 >> > www.qbs.com.pl >> >> Here is the error I am getting: >> patching file mkfs.c >> Hunk #1 FAILED at 1060. >> Hunk #2 FAILED at 1070. >> 2 out of 2 hunks FAILED -- saving rejects to file mkfs.c.rej >> patching file volumes.c >> Hunk #1 FAILED at 868. >> Hunk #2 FAILED at 920. >> 2 out of 2 hunks FAILED -- saving rejects to file volumes.c.rej >> >> I think the file I created is wrong. >> What is the accepted format for the patch command? > > You may also want to try > git checkout integration-20110626 > there were some problems with 20110630 AFAICR > > Hubert > Hey Hubert, Thanks for the suggestions I think I am using the wrong format for the patch. Can you confirm that the patch file named rem.diff should be like the one I attach on the email? I get the same error when trying git apply on both integrations: git apply ../rem.diff error: patch failed: mkfs.c:1060 error: mkfs.c: patch does not apply error: patch failed: volumes.c:888 error: volumes.c: patch does not apply I finally got it to compile the integration-20110626 by manually finding the four lines and deleting them. Here is the git diff --- diff --git a/mkfs.c b/mkfs.c index 1b5ef0
Re: TRIM support
On Mon, Jul 4, 2011 at 5:20 PM, Martin Steigerwald wrote: > Am Samstag, 2. Juli 2011 schrieben Sie: >> On Sat, 2011-07-02 at 19:08 +0100, Leonidas Spyropoulos wrote: >> > Hello, >> > >> > I just installed an archlinux with btrfs root partition and would >> > like to set the correct mount properties >> > Following this: >> > https://wiki.archlinux.org/index.php/Solid_State_Drives >> > it says there that I should use the discard mount parameter to enable >> > TRIM. >> > >> > I would like to ask by using ssd mount parameter would TRIM be >> > enabled? The SSD is Intel 320 Series 120Gb >> >> No, the "ssd" mount parameter has nothing to do with TRIM. > [...] >> The discard option is not currently automatically enabled; I think >> there may have been some performance issues in certain cases with >> drives that have slow trim implementations. But feel free to give it a >> try. > > As alternative use fstrim command from time to time or regularily during a > cron job. From what I understood it does batched discard of all free > blocks in a filesystem. > > merkaba:~> time fstrim -v / > /: 5044342784 bytes was trimmed > fstrim -v / 0,00s user 0,36s system 10% cpu 3,486 total > > merkaba:~> time fstrim -v /home > /home: 27062587392 bytes was trimmed > fstrim -v /home 0,00s user 0,92s system 20% cpu 4,512 total > > First one is BTRFS, second one is Ext4 - and will be, until I am convinced > that BTRFS has a fully featured and working fsck and until its > experimental flag is removed. > > fstrim is in util-linux(-ng) when its new enough. Do I need to run fstrim command while the partition is offline or can it be done while mounted? > > -- > Martin 'Helios' Steigerwald - http://www.Lichtvoll.de > GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TRIM support
On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel wrote: > On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: > >> The discard option is not currently automatically enabled; I think >> there may have been some performance issues in certain cases with >> drives that have slow trim implementations. But feel free to give >> it a try. > > This LWN article from 2009 explains why it can be problematic > (especially on SATA drives where TRIM is a non-queued command): > > https://lwn.net/Articles/347511/ > So the current problem with TRIM in ATA (and SATA) is that it introduce delays? As long as it keeps your SSD in a good shape it's still better than not having TRIM at all, right? Also the only viable option for now is fstrim? What is fstrim does that kernel cannot? I thought the TRIM was included as from kernel 2.6.29, no ? Cheers Leonidas > cheers, > Chris > -- > Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC > > This email may come with a PGP signature as a file. Do not panic. > For more info see: http://en.wikipedia.org/wiki/OpenPGP > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TRIM support
So any clues for the intel 320 series? I think it doesn't use compression. On Sun, Jul 10, 2011 at 10:59 PM, Fajar A. Nugraha wrote: > On Mon, Jul 11, 2011 at 3:58 AM, Leonidas Spyropoulos > wrote: >> On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel wrote: >>> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: >>> This LWN article from 2009 explains why it can be problematic >>> (especially on SATA drives where TRIM is a non-queued command): >>> >>> https://lwn.net/Articles/347511/ >>> >> So the current problem with TRIM in ATA (and SATA) is that it >> introduce delays? As long as it keeps your SSD in a good shape it's >> still better than not having TRIM at all, right? > > Not quite. > > Sandforce-based SSDs have their own way of reducing writes (e.g. by > using internal compression), so you don't have to do anything special. > Also, AFAIK currently TRIM is useless if the drives are behind a > hardware raid controller anyway. > > My Corsair F60 (on a notebook) is actually MUCH SLOWER with -o discard > (i.e. writes capped at 100 iops) > > -- > Fajar > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TRIM support
On Mon, Jul 11, 2011 at 7:04 AM, Fajar A. Nugraha wrote: > On Mon, Jul 11, 2011 at 5:34 AM, Leonidas Spyropoulos > wrote: >> So any clues for the intel 320 series? I think it doesn't use compression. > > At this point your best bet is to try it yourself and see. If it > doesn't result in poor performance, then keep on using "-o discard". Could you propose me any tools available for measuring performance? I only know iozone and tunefs -t parameter. > > -- > Fajar > >> >> On Sun, Jul 10, 2011 at 10:59 PM, Fajar A. Nugraha wrote: >>> On Mon, Jul 11, 2011 at 3:58 AM, Leonidas Spyropoulos >>> wrote: >>>> On Sun, Jul 10, 2011 at 9:33 AM, Chris Samuel wrote: >>>>> On Sun, 3 Jul 2011 05:45:17 AM Calvin Walton wrote: >>>>> This LWN article from 2009 explains why it can be problematic >>>>> (especially on SATA drives where TRIM is a non-queued command): >>>>> >>>>> https://lwn.net/Articles/347511/ >>>>> >>>> So the current problem with TRIM in ATA (and SATA) is that it >>>> introduce delays? As long as it keeps your SSD in a good shape it's >>>> still better than not having TRIM at all, right? >>> >>> Not quite. >>> >>> Sandforce-based SSDs have their own way of reducing writes (e.g. by >>> using internal compression), so you don't have to do anything special. >>> Also, AFAIK currently TRIM is useless if the drives are behind a >>> hardware raid controller anyway. >>> >>> My Corsair F60 (on a notebook) is actually MUCH SLOWER with -o discard >>> (i.e. writes capped at 100 iops) > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ccache on btrfs
Hi Is there an issue with btrfs ccache and multiple threads during compilation? I'm experiencing kernel panics while building Linux kernel on a btrfs system with -j8 and ccache enabled. Google suggest there was some issue on earlier kernels but my kernel is 3.16+ Anyone can confirm? Thanks Leonidas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ccache on btrfs
On 17/10/14, Timofey Titovets wrote: > i use ccache and often compile linux from git, > I don't catch any errors with it. > Interesting, I re-enabled ccache on an ext4 partition (HDD) and worked fine. So I suspect it's something to do with btrfs and SSD. My mount options are: /dev/sda3 on /home type btrfs (rw,relatime,ssd,discard,nospace_cache) The problem is that I can't get hold of kernel panic since it's not in the journal [1]. I don't know a way to get hold of the kernel panic log to help anyway. What would it be useful to debug it? [1] using systemd Leonidas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Current State of BTRFS
On Mon, Feb 11, 2013 at 4:05 PM, Josef Bacik wrote:
> On Fri, Feb 08, 2013 at 04:12:17PM -0700, Florian Hofmann wrote:
>> I ran it as root. The first times there was no output whatsoever. This
>> time triggering gave the SysRq : Show Blocked State line. Strange
>>
>
> Well that's weird, it looks like you don't have any blocked tasks, so either
> sysrq+w is screwing up or you are getting stuck in something CPU intensive.
> Try
> doing sysrq+w next time it happens again and also run top and see if something
> is using up 100% of the CPU. If it's something chewing up CPU then I'll tell
> you how to figure out what's going on. Thanks,
>
I noticed you have the FS mounted with compress flag (compress=lzo).
Could it be that your CPU is bottle-necking the process?
> Josef
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Caution: breathing may be hazardous to your health.
#include
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: No space left on device
On 12/02/2014 09:51, Jakob Truelsen wrote: Hello. I am experiencing "No space left on device" with a btrfs file system, yet I cannot seem to find any exhausted resource. Could some resource I do not know about be exhausted, or is this caused by something else. Below is a trace of information that might be usefull, please let me know if there is anything I can do to resolve the issue. /Jakob [jakobt@soda ~]$ uname -a Linux soda 3.12.8-1-ARCH #1 SMP PREEMPT Thu Jan 16 09:16:34 CET 2014 x86_64 GNU/Linux [jakobt@soda ~]$ btrfs --version Btrfs v3.12 [jakobt@soda ~]$ mount ... /dev/sda on /data type btrfs (rw,relatime,nospace_cache) [jakobt@soda ~]$ df /data Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb2 76594224 49247368 23433028 68% / [jakobt@soda ~]$ btrfs filesystem df /data Data, single: total=1.82TiB, used=518.04GiB System, DUP: total=8.00MiB, used=204.00KiB System, single: total=4.00MiB, used=0.00 Metadata, DUP: total=1.00GiB, used=767.70MiB Metadata, single: total=8.00MiB, used=0.00 [jakobt@soda ~]$ touch /data/jakobt/hat touch: cannot touch ‘/data/jakobt/hat’: No space left on device [jakobt@soda ~]$ sudo btrfs fi balance start /data ERROR: error during balancing '/data' - No space left on device There may be more info in syslog - try dmesg | tail [jakobt@soda ~]$ dmesg | grep tail -n 2 [1113177.878157] btrfs: device label Data devid 1 transid 44784 /dev/sda [1113507.641752] btrfs: 1866 enospc errors during balance [jakobt@soda ~]$ sudo umount /data [jakobt@soda ~]$ sudo btrfsck /dev/sda ... cache and super generation don't match, space cache will be invalidated .. found 172181366447 bytes used err is 0 total csum bytes: 418841160 total tree bytes: 805187584 total fs tree bytes: 247164928 total extent tree bytes: 26329088 btree space waste bytes: 164771401 file data blocks allocated: 561564688384 referenced 511759908864 Btrfs v3.12 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Jacob, Have you tried balancing just the data/metadata chunks only? Regards, Leonidas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs balance enospc
On 15/09/14, Mark Murawski wrote: > I should have plenty of space for this operation, but it fails > > [...] This might be useful: https://btrfs.wiki.kernel.org/index.php/Balance_Filters Regards, Leonidas -- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs-progs repository
Hello, Why the official repository is not updated with the latest patched for gcc 4.6? I noticed that http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ includes more patches than the git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git So I was wondering is it some kind of testing to be done on patches to be included into the official repo? Another thing is that there are commands for creating the build enviroment for fedora and debian but I found nowhere in the wiki the dependencies of the btrfs-progs to compile them. Shouldn't be a list of packages or dependencies for it? Thanks Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs-progs repository
On Thu, Aug 4, 2011 at 11:01 AM, Hugo Mills wrote: > On Thu, Aug 04, 2011 at 10:45:30AM +0100, Leonidas Spyropoulos wrote: >> Why the official repository is not updated with the latest patched for gcc >> 4.6? >> I noticed that http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ >> includes more patches than the >> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git >> >> So I was wondering is it some kind of testing to be done on patches to >> be included into the official repo? > > There have been a lot of patches published in the 9 months or so > since the upstream repo was last updated -- Chris has been > concentrating on other things (like kernel-side stability and the new > fsck). I pulled them all into one place and started to try to make > sense of them all, which is the ongoing work that is the darksatanic > repo. > > There's a for-chris branch (which is actually the same as my master > branch now), which is the "stable" patches that have (mostly) been > reviewed. Then there's the integration-* branches, which are general > dumps of things that aren't ready to go upstream yet, but which I'm > publishing simply to get patches available for testing (particularly > new features like scrub). > > I should probably send Chris another pull request. :) The only reason for me to search the mailing list for an alternative repository (and I send the message after) was because with the latest stable gcc 4.6 it doesn't compile due to some unused variables (WARNINGS) so your repository seems to compile fine. I wasn't after some cool new untested feature tbh, just the latest btrfs. Would be cool to update it. > >> Another thing is that there are commands for creating the build >> enviroment for fedora and debian but I found nowhere in the wiki the >> dependencies of the btrfs-progs to compile them. >> Shouldn't be a list of packages or dependencies for it? > > The website is a wiki, so feel free to update the instructions with > anything you've found to be missing. And I'll happily accept patches > to any instructions that are shipped with the userspace tools. :) I would be happy to update the wiki if I knew the dependencies :P And I don't know what you mean with the patched to userspace tools, sorry for my naiveness. (even If I make a patch I don't know how to actually produce the standartize patch mails I see on the mailing list, but that's out of the mailing list question; would be grateful in an off-the-list email with instructions). > > (I believe the only dependencies are libuuid and libxattr -- > whatever they're called on $distribution). No idea and when I searched on Arch linux for those packages didn't find any with that name, should be under another package. > > Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- emacs: Eighty Megabytes And Constantly Swapping. --- > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iD8DBQFOOm4GIKyzvlFcI40RAhsRAJ9G+zIkvJcOAxJp/bACRlLFYqbwIwCggMaU > mMaunZQG3NDI4yazFuC517Y= > =GQRp > -END PGP SIGNATURE- > > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs-progs repository
On Thu, Aug 4, 2011 at 11:14 AM, Helmut Hullen wrote: > Hallo, Leonidas, > > Du meintest am 04.08.11: > >> Another thing is that there are commands for creating the build >> enviroment for fedora and debian but I found nowhere in the wiki the >> dependencies of the btrfs-progs to compile them. >> Shouldn't be a list of packages or dependencies for it? > > Have you already studied the "INSTALL" file? Right, it's mentioned there must have missed it when I read the INSTALL months ago.. I didn't think it would change :P > > Viele Gruesse! > Helmut > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs-progs repository
Updated the wiki accordingly On Thu, Aug 4, 2011 at 2:20 PM, Leonidas Spyropoulos wrote: > On Thu, Aug 4, 2011 at 11:14 AM, Helmut Hullen wrote: >> Hallo, Leonidas, >> >> Du meintest am 04.08.11: >> >>> Another thing is that there are commands for creating the build >>> enviroment for fedora and debian but I found nowhere in the wiki the >>> dependencies of the btrfs-progs to compile them. >>> Shouldn't be a list of packages or dependencies for it? >> >> Have you already studied the "INSTALL" file? > Right, it's mentioned there must have missed it when I read the > INSTALL months ago.. > I didn't think it would change :P > >> >> Viele Gruesse! >> Helmut >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > > -- > Caution: breathing may be hazardous to your health. > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel BUG unable to handle kernel NULL pointer dereference
Hello, I got a kernel bug error, my guess from BTRFS. Here is the report, Oct 22 20:44:43 localhost kernel: [25554.947970] BUG: unable to handle kernel NULL pointer dereference at 0030 Oct 22 20:44:43 localhost kernel: [25554.948002] IP: [] btrfs_print_leaf+0x37/0x880 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948037] PGD bfa44067 PUD bfa43067 PMD 0 Oct 22 20:44:43 localhost kernel: [25554.948052] Oops: [#1] PREEMPT SMP Oct 22 20:44:43 localhost kernel: [25554.948066] CPU 1 Oct 22 20:44:43 localhost kernel: [25554.948072] Modules linked in: nls_cp437 vfat fat ipv6 loop fuse hid_apple usbhid hid uvcvideo videodev media v4l2_compat_ioctl32 adt7475 hwmon_vid evdev nouveau snd_emu10k1 snd_rawmidi snd_intel8x0 ttm drm_kms_helper sg snd_ac97_codec snd_seq_device firewire_ohci drm snd_util_mem ac97_bus snd_pcm snd_hwdep edac_core k8temp psmouse firewire_core emu10k1_gp snd_timer edac_mce_amd pcspkr snd i2c_algo_bit gameport mxm_wmi wmi crc_itu_t serio_raw soundcore video snd_page_alloc fan i2c_nforce2 thermal i2c_core floppy processor button uas usb_storage forcedeth btrfs zlib_deflate crc32c libcrc32c ext4 jbd2 crc16 ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sr_mod sd_mod cdrom sata_nv pata_amd libata scsi_mod Oct 22 20:44:43 localhost kernel: [25554.948321] Oct 22 20:44:43 localhost kernel: [25554.948327] Pid: 4834, comm: firefox Not tainted 3.0-ARCH #1/LP UT NF4 Expert Oct 22 20:44:43 localhost kernel: [25554.948522] RIP: 0010:[] [] btrfs_print_leaf+0x37/0x880 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948547] RSP: 0018:8800b341fb38 EFLAGS: 00010282 Oct 22 20:44:43 localhost kernel: [25554.948557] RAX: ffe4 RBX: RCX: 8800b341ffd8 Oct 22 20:44:43 localhost kernel: [25554.948570] RDX: 8800b341e000 RSI: RDI: 880135075000 Oct 22 20:44:43 localhost kernel: [25554.948582] RBP: 8800b341fbc8 R08: R09: Oct 22 20:44:43 localhost kernel: [25554.948595] R10: ffe4 R11: R12: 0005 Oct 22 20:44:43 localhost kernel: [25554.948607] R13: 05114000 R14: ffe4 R15: 1000 Oct 22 20:44:43 localhost kernel: [25554.948621] FS: 7f1c5a2f4720() GS:88013fd0() knlGS:f68227f0 Oct 22 20:44:43 localhost kernel: [25554.948634] CS: 0010 DS: ES: CR0: 80050033 Oct 22 20:44:43 localhost kernel: [25554.948645] CR2: 0030 CR3: bfa41000 CR4: 06e0 Oct 22 20:44:43 localhost kernel: [25554.948658] DR0: DR1: DR2: Oct 22 20:44:43 localhost kernel: [25554.948670] DR3: DR6: 0ff0 DR7: 0400 Oct 22 20:44:43 localhost kernel: [25554.948683] Process firefox (pid: 4834, threadinfo 8800b341e000, task 88012d817300) Oct 22 20:44:43 localhost kernel: [25554.948701] Stack: Oct 22 20:44:43 localhost kernel: [25554.948708] 2000 1000 8800b341fc70 05114000 Oct 22 20:44:43 localhost kernel: [25554.948730] 0282 81142c03 880135075000 0090 Oct 22 20:44:43 localhost kernel: [25554.948755] 0090 805037106510 a8051140 1000 Oct 22 20:44:43 localhost kernel: [25554.948777] Call Trace: Oct 22 20:44:43 localhost kernel: [25554.948787] [] ? kmem_cache_alloc+0x133/0x160 Oct 22 20:44:43 localhost kernel: [25554.948807] [] __btrfs_free_extent+0x61f/0x6d0 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948827] [] ? run_clustered_refs+0x11d/0x830 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948847] [] run_clustered_refs+0x389/0x830 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948867] [] btrfs_run_delayed_refs+0xc8/0x220 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948881] [] ? mutex_unlock+0xe/0x10 Oct 22 20:44:43 localhost kernel: [25554.948900] [] btrfs_commit_transaction+0x81/0x8a0 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948915] [] ? abort_exclusive_wait+0xb0/0xb0 Oct 22 20:44:43 localhost kernel: [25554.948928] [] ? dput+0x10e/0x1a0 Oct 22 20:44:43 localhost kernel: [25554.948948] [] btrfs_sync_file+0x194/0x1e0 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.948961] [] vfs_fsync_range+0x5f/0xa0 Oct 22 20:44:43 localhost kernel: [25554.948973] [] vfs_fsync+0x1c/0x20 Oct 22 20:44:43 localhost kernel: [25554.948984] [] sys_fsync+0x33/0x50 Oct 22 20:44:43 localhost kernel: [25554.948995] [] system_call_fastpath+0x16/0x1b Oct 22 20:44:43 localhost kernel: [25554.949008] Code: 89 5d d8 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 65 48 8b 0c 25 48 cd 00 00 48 8d 91 28 e0 ff ff 48 89 f3 Oct 22 20:44:43 localhost kernel: [25554.949269] RIP [] btrfs_print_leaf+0x37/0x880 [btrfs] Oct 22 20:44:43 localhost kernel: [25554.949292] RSP Oct 22 20:44:43 localhost kernel: [25554.949300] CR2: 0030 Oct 22 20:44:43 localhost kernel: [25554.957960] ---
Re: Kernel BUG unable to handle kernel NULL pointer dereference
On Sun, Oct 23, 2011 at 4:37 PM, Mitch Harder wrote: > On Sat, Oct 22, 2011 at 3:23 PM, Leonidas Spyropoulos > wrote: >> Hello, I got a kernel bug error, my guess from BTRFS. >> >> Here is the report, >> Oct 22 20:44:43 localhost kernel: [25554.947970] BUG: unable to handle >> kernel NULL pointer dereference at 0030 >> Oct 22 20:44:43 localhost kernel: [25554.948002] IP: >> [] btrfs_print_leaf+0x37/0x880 [btrfs] > > A patch was submitted by Sergei Trofimovich to address the issue with > handling a NULL pointer in btrfs_print_leaf. > > http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg12021.html > > Unfortunately, this usually only crops up when btrfs runs into > corruptions that it can't handle. So you very likely still have > problems even if the btrfs_print_leaf issue isn't addressed. > So from what I understand btrfs_print_leaf function is called only when something is wrong and want to print out debug information, correct? How can I track down the real problem? Any suggestions? -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel BUG unable to handle kernel NULL pointer dereference
On Mon, Oct 24, 2011 at 12:22 PM, David Sterba wrote: > On Sun, Oct 23, 2011 at 07:24:42PM +0100, Leonidas Spyropoulos wrote: >> On Sun, Oct 23, 2011 at 4:37 PM, Mitch Harder >> wrote: >> > A patch was submitted by Sergei Trofimovich to address the issue with >> > handling a NULL pointer in btrfs_print_leaf. >> > >> > http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg12021.html > > afaik the patch should be enqueued for 3.2 > >> How can I track down the real problem? Any suggestions? > > The preceding function in the stack was __btrfs_free_extent, there are 3 > instances of btrfs_print_leaf() in that function, 2 of them relevant: > > 4470 printk(KERN_ERR "umm, got %d back from > search" > 4471 ", was looking for %llu\n", ret, > 4472 (unsigned long long)bytenr); > > > 4494 #ifdef BTRFS_COMPAT_EXTENT_TREE_V0 > ... > 4511 printk(KERN_ERR "umm, got %d back from search" > 4512 ", was looking for %llu\n", ret, > 4513 (unsigned long long)bytenr); > 4514 btrfs_print_leaf(extent_root, path->nodes[0]); > ... > #endif > > and the third one without a pre-message > > 4481 btrfs_print_leaf(extent_root, path->nodes[0]); > 4482 WARN_ON(1); > 4483 printk(KERN_ERR "btrfs unable to find ref byte nr %llu " > 4484 "parent %llu root %llu owner %llu offset %llu\n", > 4485 (unsigned long long)bytenr, > 4486 (unsigned long long)parent, > 4487 (unsigned long long)root_objectid, > 4488 (unsigned long long)owner_objectid, > 4489 (unsigned long long)owner_offset); > > > your original report does not contain any messages before the BUG > listing, so I'm not sure which one it is. I got the whole log somwehre lying arround, let me find it and give a pastbin link Here is it, it's big and contains usless information.. http://paste.pocoo.org/show/497299/ > > Supposed it's the 3rd, it's resulting from an error returned by > > 4429 ret = lookup_extent_backref(trans, extent_root, path, &iref, > 4430 bytenr, num_bytes, parent, > 4431 root_objectid, owner_objectid, > 4432 owner_offset); > > ret != 0 -> print leaf etc, a missing backref could be the problem here. > > Are you able to trigger the BUG() repeatedly? No I cannot reproduce it intentionally, it was quite random, while playing something in the SMPlayer - think it was a movie. The movie kept playing, and I can start programs (that was on the memory I assume), couldn't access the FS at all. ls failed for example. So I just hard-reboot and hoped all was alright. So far I didn't see any problems after that. > > > david > Thanks for checking it Regards Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel BUG unable to handle kernel NULL pointer dereference
On Mon, Oct 24, 2011 at 12:51 PM, David Sterba wrote: > On Mon, Oct 24, 2011 at 12:33:05PM +0100, Leonidas Spyropoulos wrote: >> Here is it, it's big and contains usless information.. >> >> http://paste.pocoo.org/show/497299/ > > not all that useless ... I saw another BUG earlier than the one you've > reported: > > [31653.267742] [ cut here ] > [31653.267764] kernel BUG at fs/btrfs/extent-tree.c:5510! > [31653.267773] invalid opcode: [#1] PREEMPT SMP > [31653.267785] CPU 1 > [31653.267790] Modules linked in: vboxdrv ipv6 loop fuse adt7475 hwmon_vid > nouveau evdev uvcvideo hid_apple ttm videodev drm_kms_helper media > v4l2_compat_ioctl32 drm snd_emu10k1 i2c_algo_bit mxm_wmi wmi pcspkr > snd_rawmidi snd_seq_device firewire_ohci emu10k1_gp edac_core psmouse > snd_util_mem edac_mce_amd k8temp firewire_core gameport snd_hwdep video > serio_raw crc_itu_t sg snd_intel8x0 snd_ac97_codec usbhid ac97_bus snd_pcm > snd_timer hid snd floppy i2c_nforce2 thermal processor fan button soundcore > i2c_core snd_page_alloc forcedeth btrfs zlib_deflate crc32c libcrc32c ext4 > jbd2 crc16 ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sr_mod sd_mod cdrom > sata_nv pata_amd libata scsi_mod > [31653.267989] > [31653.267995] Pid: 726, comm: btrfs-transacti Not tainted 3.0-ARCH #1 /LP > UT NF4 Expert > [31653.268011] RIP: 0010:[] [] > run_clustered_refs+0x813/0x830 [btrfs] > [31653.268045] RSP: 0018:88013469bc70 EFLAGS: 00010286 > [31653.268286] RAX: ffe4 RBX: 88012e406900 RCX: > 8801378a6100 > [31653.268296] RDX: 88011513a0f0 RSI: RDI: > > [31653.268306] RBP: 88013469bd50 R08: R09: > > [31653.268315] R10: 8801346f9800 R11: 88013735d3f0 R12: > 8800a9bc7f00 > [31653.268325] R13: 88007b1d7e40 R14: 88011bd1e4b0 R15: > > [31653.268341] FS: 7f8dcc527880() GS:88013fd0() > knlGS:f67567f0 > [31653.268367] CS: 0010 DS: ES: CR0: 8005003b > [31653.268380] CR2: 7f9059631550 CR3: a499c000 CR4: > 06e0 > [31653.268394] DR0: DR1: DR2: > > [31653.268409] DR3: DR6: 0ff0 DR7: > 0400 > [31653.268424] Process btrfs-transacti (pid: 726, threadinfo > 88013469a000, task 880136c140b0) > [31653.268443] Stack: > [31653.268449] 88010001 > > [31653.268473] 0c2e a01dc529 > 0002 > [31653.268495] 0b9f 0c04 > 88013469bd90 > [31653.268515] Call Trace: > [31653.268531] [] btrfs_run_delayed_refs+0xc8/0x220 [btrfs] > [31653.268549] [] ? btrfs_free_path+0x2a/0x40 [btrfs] > [31653.268568] [] btrfs_commit_transaction+0x3c3/0x8a0 > [btrfs] > [31653.268581] [] ? abort_exclusive_wait+0xb0/0xb0 > [31653.268598] [] transaction_kthread+0x26d/0x290 [btrfs] > [31653.268617] [] ? btrfs_congested_fn+0xd0/0xd0 [btrfs] > [31653.268627] [] kthread+0x8c/0xa0 > [31653.268638] [] kernel_thread_helper+0x4/0x10 > [31653.268647] [] ? kthread_worker_fn+0x190/0x190 > [31653.268657] [] ? gs_change+0x13/0x13 > [31653.268673] Code: e0 e9 12 f9 ff ff 0f 0b 80 fa b2 0f 84 bc f9 ff ff 0f 0b > be 95 00 00 00 48 c7 c7 37 d0 20 a0 e8 54 65 eb e0 e9 04 f9 ff ff 0f 0b <0f> > 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 66 66 66 66 66 66 2e > [31653.268928] RIP [] run_clustered_refs+0x813/0x830 > [btrfs] > [31653.268956] RSP > [31653.284196] ---[ end trace d5d8ee7634d1c36e ]--- > > and it looks related to the print_leaf bug later (eg. mentiones same functions > in the stacktrace and happens during commit). > > And judging from the rest of BUG's in the paste, the filesystem is in a bad > shape. Some BUG_ON's seem to be triggered by ENOSPC (RAX containing > 0xfff..e4). > > > david > I am doing a backup of my current data as I write this mail (hopefully it will finish without IO errors). Will it help if I print the btrfs tree and post it somewhere? I mean, since the system is funcionable, it could be useful to track down the bug, no? Regards Leonidas -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel BUG unable to handle kernel NULL pointer dereference
On Mon, Oct 24, 2011 at 1:10 PM, Leonidas Spyropoulos wrote: > On Mon, Oct 24, 2011 at 12:51 PM, David Sterba wrote: >> On Mon, Oct 24, 2011 at 12:33:05PM +0100, Leonidas Spyropoulos wrote: >>> Here is it, it's big and contains usless information.. >>> >>> http://paste.pocoo.org/show/497299/ >> >> not all that useless ... I saw another BUG earlier than the one you've >> reported: >> >> [31653.267742] [ cut here ] >> [31653.267764] kernel BUG at fs/btrfs/extent-tree.c:5510! >> [31653.267773] invalid opcode: [#1] PREEMPT SMP >> [31653.267785] CPU 1 >> [31653.267790] Modules linked in: vboxdrv ipv6 loop fuse adt7475 hwmon_vid >> nouveau evdev uvcvideo hid_apple ttm videodev drm_kms_helper media >> v4l2_compat_ioctl32 drm snd_emu10k1 i2c_algo_bit mxm_wmi wmi pcspkr >> snd_rawmidi snd_seq_device firewire_ohci emu10k1_gp edac_core psmouse >> snd_util_mem edac_mce_amd k8temp firewire_core gameport snd_hwdep video >> serio_raw crc_itu_t sg snd_intel8x0 snd_ac97_codec usbhid ac97_bus snd_pcm >> snd_timer hid snd floppy i2c_nforce2 thermal processor fan button soundcore >> i2c_core snd_page_alloc forcedeth btrfs zlib_deflate crc32c libcrc32c ext4 >> jbd2 crc16 ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sr_mod sd_mod cdrom >> sata_nv pata_amd libata scsi_mod >> [31653.267989] >> [31653.267995] Pid: 726, comm: btrfs-transacti Not tainted 3.0-ARCH #1 >> /LP UT NF4 Expert >> [31653.268011] RIP: 0010:[] [] >> run_clustered_refs+0x813/0x830 [btrfs] >> [31653.268045] RSP: 0018:88013469bc70 EFLAGS: 00010286 >> [31653.268286] RAX: ffe4 RBX: 88012e406900 RCX: >> 8801378a6100 >> [31653.268296] RDX: 88011513a0f0 RSI: RDI: >> >> [31653.268306] RBP: 88013469bd50 R08: R09: >> >> [31653.268315] R10: 8801346f9800 R11: 88013735d3f0 R12: >> 8800a9bc7f00 >> [31653.268325] R13: 88007b1d7e40 R14: 88011bd1e4b0 R15: >> >> [31653.268341] FS: 7f8dcc527880() GS:88013fd0() >> knlGS:f67567f0 >> [31653.268367] CS: 0010 DS: ES: CR0: 8005003b >> [31653.268380] CR2: 7f9059631550 CR3: a499c000 CR4: >> 06e0 >> [31653.268394] DR0: DR1: DR2: >> >> [31653.268409] DR3: DR6: 0ff0 DR7: >> 0400 >> [31653.268424] Process btrfs-transacti (pid: 726, threadinfo >> 88013469a000, task 880136c140b0) >> [31653.268443] Stack: >> [31653.268449] 88010001 >> >> [31653.268473] 0c2e a01dc529 >> 0002 >> [31653.268495] 0b9f 0c04 >> 88013469bd90 >> [31653.268515] Call Trace: >> [31653.268531] [] btrfs_run_delayed_refs+0xc8/0x220 >> [btrfs] >> [31653.268549] [] ? btrfs_free_path+0x2a/0x40 [btrfs] >> [31653.268568] [] btrfs_commit_transaction+0x3c3/0x8a0 >> [btrfs] >> [31653.268581] [] ? abort_exclusive_wait+0xb0/0xb0 >> [31653.268598] [] transaction_kthread+0x26d/0x290 [btrfs] >> [31653.268617] [] ? btrfs_congested_fn+0xd0/0xd0 [btrfs] >> [31653.268627] [] kthread+0x8c/0xa0 >> [31653.268638] [] kernel_thread_helper+0x4/0x10 >> [31653.268647] [] ? kthread_worker_fn+0x190/0x190 >> [31653.268657] [] ? gs_change+0x13/0x13 >> [31653.268673] Code: e0 e9 12 f9 ff ff 0f 0b 80 fa b2 0f 84 bc f9 ff ff 0f >> 0b be 95 00 00 00 48 c7 c7 37 d0 20 a0 e8 54 65 eb e0 e9 04 f9 ff ff 0f 0b >> <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 66 66 66 66 66 66 2e >> [31653.268928] RIP [] run_clustered_refs+0x813/0x830 >> [btrfs] >> [31653.268956] RSP >> [31653.284196] ---[ end trace d5d8ee7634d1c36e ]--- >> >> and it looks related to the print_leaf bug later (eg. mentiones same >> functions >> in the stacktrace and happens during commit). >> >> And judging from the rest of BUG's in the paste, the filesystem is in a bad >> shape. Some BUG_ON's seem to be triggered by ENOSPC (RAX containing >> 0xfff..e4). >> >> >> david >> > > I am doing a backup of my current data as I write this mail (hopefully > it will finish without IO errors). > Will it help if I print the btrfs tree and post it somewhere? > > I mean, since the system is funcionable, it could be useful to track > down the bug, no? >
Re: https://btrfs.wiki.kernel.org/index.php/Main_Page
On Mon, Oct 17, 2011 at 2:17 PM, Hugo Mills wrote: > On Mon, Oct 17, 2011 at 09:07:53PM +0800, Anand Jain wrote: >> >> Does not load. Wondering if this should work or has been moved ? > > It's a victim of the kernel.org hack. Nobody seems to have a spare > copy, but the database on kernel.org should still be there. I think > we're just waiting for the dust to settle on kernel.org (they're still > getting git access back for the main kernel developers) before we can > find out about continued wiki support, or getting the wiki data back. Do we have an update to this? If not is it possible to ask a db dump and make a temporary wiki live somewhere else until the kernel.org is fully operational again? > > Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- You can get more with a kind word and a two-by-four than you --- > can with just a kind word. > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: https://btrfs.wiki.kernel.org/index.php/Main_Page
On Wed, Nov 2, 2011 at 10:22 AM, Hugo Mills wrote: > On Wed, Nov 02, 2011 at 10:00:19AM +0000, Leonidas Spyropoulos wrote: >> On Mon, Oct 17, 2011 at 2:17 PM, Hugo Mills wrote: >> > On Mon, Oct 17, 2011 at 09:07:53PM +0800, Anand Jain wrote: >> >> >> >> Does not load. Wondering if this should work or has been moved ? >> > >> > It's a victim of the kernel.org hack. Nobody seems to have a spare >> > copy, but the database on kernel.org should still be there. I think >> > we're just waiting for the dust to settle on kernel.org (they're still >> > getting git access back for the main kernel developers) before we can >> > find out about continued wiki support, or getting the wiki data back. >> >> Do we have an update to this? If not is it possible to ask a db dump >> and make a temporary wiki live somewhere else until the kernel.org is >> fully operational again? > > It's expected to be back online at the end of this week. If they > can't get it back by then, we've been promised a DB dump. Ok good to know that. Let's hope it comes up on Friday. > > Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- 2 + 2 = 5, for sufficiently large values of 2. --- > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs-progs
Hi, On Tue, Nov 1, 2011 at 4:34 PM, Andrew Benton wrote: > Hello, > > I've just pulled btrfs-progs from the new git repo > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git > However, when I come to make it fails like so: > > gcc -Wp,-MMD,./.btrfsctl.o.d,-MT,btrfsctl.o -Wall -D_FILE_OFFSET_BITS=64 > -D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfsctl.c > gcc -g -Werror -Os -o btrfsctl btrfsctl.o ctree.o disk-io.o radix-tree.o > extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o > inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o > btrfs-list.o btrfslabel.o -luuid > ls mkfs.c > mkfs.c > gcc -Wp,-MMD,./.mkfs.o.d,-MT,mkfs.o -Wall -D_FILE_OFFSET_BITS=64 > -D_FORTIFY_SOURCE=2 -g -Werror -Os -c mkfs.c > mkfs.c:39:24: fatal error: attr/xattr.h: No such file or directory > compilation terminated. > make: *** [mkfs.o] Error 1 > andy@eccles:~/btrfs-progs$ > > Is attr a required dependency of btrfs-progs now? > If I sed -i 's#attr/#sys/#' mkfs.c then it compiles and installs (I've > not tried to use any of the tools yet). Is it wise to do this? I don't > use any extended attributes, I don't have extended attributes enabled > in my kernel config, I have no wish to install libattr. > > Please CC me as I'm not subscribed, I just cloned the repo and compiled it without problems on an up-to-date Archlinux x86-64 system As far as dependencies the only one needed is: libuuid Quoting the INSTALL file: ... The Btrfs utility programs require libuuid to build. This can be found in the e2fsprogs sources, and is usually available as libuuid or e2fsprogs-devel from various distros. ... As for the xattr.h file I searched my system and I am guessing my compilation it's using the file located in /usr/include/attr/xattr.h (because I got multiple ones in different locations) This seems to be coming from attr package. pkgfile /usr/include/attr/xattr.h core/attr But searching for this file outside that path it seems like the linux-headers contain it as well. So it could be a solution to use the one from the headers? Maybe someone else can light a bit more some corners of my procedure. :) Hope I helped. Leonidas > > Andy > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Caution: breathing may be hazardous to your health. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
