[PATCH] btrfs: fix memory leakage
The memory allocated to name by function extref_get_fields isn't properly
freed when error occurs.
Signed-off-by: Cong Ding ding...@gmail.com
---
fs/btrfs/tree-log.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 79f057c..e75f3ed 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1169,8 +1169,10 @@ static noinline int add_inode_ref(struct
btrfs_trans_handle *trans,
*/
if (!dir)
dir = read_one_inode(root, parent_objectid);
- if (!dir)
+ if (!dir) {
+ kfree(name);
return -ENOENT;
+ }
} else {
ret = ref_get_fields(eb, ref_ptr, namelen, name,
ref_index);
--
1.7.9.5
--
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, problem
On Sun, Oct 27, 2013 at 2:00 AM, Tomasz Chmielewski t...@virtall.com wrote: Still no messages. Parameter seems to be active as /sys/module/printk/parameters/ignore_loglevel is Y, but there are no messages in log files or dmesg. Maybe I need to turn on some kernel debugging option and recompile kernel ? Also I should mention that cca 230G+ data was copied before this error started to occur. I think I saw a similar issue before. Can you try using rsync with --bwlimit XY option to copy the files? The option will limit the speed, in kB, at which the file is being copied; it will work even when source and destination files are on a local machine. Also I run strace cp -a .. ... read(3, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 write(4, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 read(3, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = 65536 write(4, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = -1 ENOSPC (No space left on device) Last two write calls take a lot more time, and then last one returns ENOSPC. But if this write is retryed, then it succeeds. I tried with midnight commander and when error occurs, if I Retry operation then it finishes copying this file until error occurs again at next file. With --bwlimit it seems to be better, lower the speed later the error occurs, and if it's slow enough copy is successfull. But now I'm not sure anymore. I copied a few files with bwlimit, and now sudenly error doesn't occur anymore, even with no bwlimit. I'll do some more tests. -- 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, problem
On 2013/10/27 10:50 AM, Igor M wrote: On Sun, Oct 27, 2013 at 2:00 AM, Tomasz Chmielewski t...@virtall.com wrote: Still no messages. Parameter seems to be active as /sys/module/printk/parameters/ignore_loglevel is Y, but there are no messages in log files or dmesg. Maybe I need to turn on some kernel debugging option and recompile kernel ? Also I should mention that cca 230G+ data was copied before this error started to occur. I think I saw a similar issue before. Can you try using rsync with --bwlimit XY option to copy the files? The option will limit the speed, in kB, at which the file is being copied; it will work even when source and destination files are on a local machine. Also I run strace cp -a .. ... read(3, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 write(4, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 read(3, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = 65536 write(4, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = -1 ENOSPC (No space left on device) Last two write calls take a lot more time, and then last one returns ENOSPC. But if this write is retryed, then it succeeds. I tried with midnight commander and when error occurs, if I Retry operation then it finishes copying this file until error occurs again at next file. With --bwlimit it seems to be better, lower the speed later the error occurs, and if it's slow enough copy is successfull. But now I'm not sure anymore. I copied a few files with bwlimit, and now sudenly error doesn't occur anymore, even with no bwlimit. I'll do some more tests. -- 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 This sounds to me like the problem is related to read performance causing a bork. This would explain why bwlimit helps, as well as why cp works the second time around (since it is cached). -- __ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97 -- 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: 3.11 and 3.12rc continual hard lock ups
Hi Chris, I set dmesg -n7 and didn't see anything extra logged (I had to use sudo to enable it. I am not familiar with sysrq-w and sysrq-t, however you ask while it is locked, this is a real hard lock. everything is unresponsive and the machine even fails to respond to ping request. It happened again over night and again the only clues where the btrfs-transaction and btrfs-flush_del going ballistic. Regards Sean Clarke - SEC Consulting Limited Phone: +44 (0)23 8040 5599 Website: http://www.sec-consulting.co.uk Email: sean.cla...@sec-consulting.co.uk On Thu, Oct 24, 2013 at 9:47 AM, Chris Mason chris.ma...@fusionio.com wrote: Quoting Sean Clarke (2013-10-23 15:26:15) Hi, I have an Intel Core i7 based fileserver with 18TB BTRFS in a 6x 3TB RAID 1+0 configuration. The system was working fine running Ubuntu 13.04 (kernel 3.11.0-12-generic). The system was upgraded to Ubuntu 13.10 (kernel 3.11) and began to lock up daily, sometimes every couple of hours. Previously it never crashed and was only taken down for maintenance so a bug was files on launchpad (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1237794). Does your kernel config include the softlockup detector? If you could please do sysrq-w and sysrq-t while it is locked, it'll help us track it down. It will be much easier if you have a serial console or network console, and you've increased your kernel logging level to the highest value (dmesg -n7) -chris -- 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, problem
On Sun, Oct 27, 2013 at 9:56 AM, Brendan Hide bren...@swiftspirit.co.za wrote: On 2013/10/27 10:50 AM, Igor M wrote: On Sun, Oct 27, 2013 at 2:00 AM, Tomasz Chmielewski t...@virtall.com wrote: Still no messages. Parameter seems to be active as /sys/module/printk/parameters/ignore_loglevel is Y, but there are no messages in log files or dmesg. Maybe I need to turn on some kernel debugging option and recompile kernel ? Also I should mention that cca 230G+ data was copied before this error started to occur. I think I saw a similar issue before. Can you try using rsync with --bwlimit XY option to copy the files? The option will limit the speed, in kB, at which the file is being copied; it will work even when source and destination files are on a local machine. Also I run strace cp -a .. ... read(3, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 write(4, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 read(3, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = 65536 write(4, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = -1 ENOSPC (No space left on device) Last two write calls take a lot more time, and then last one returns ENOSPC. But if this write is retryed, then it succeeds. I tried with midnight commander and when error occurs, if I Retry operation then it finishes copying this file until error occurs again at next file. With --bwlimit it seems to be better, lower the speed later the error occurs, and if it's slow enough copy is successfull. But now I'm not sure anymore. I copied a few files with bwlimit, and now sudenly error doesn't occur anymore, even with no bwlimit. I'll do some more tests. -- 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 This sounds to me like the problem is related to read performance causing a bork. This would explain why bwlimit helps, as well as why cp works the second time around (since it is cached). cp doesn't work second time. cp always fails. If last write() call is retryed it works, I think this midnight commander do, if you choose 'retry'. It doesn't copy from begining it continues where it left. I also tried from different disk, same result. -- 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
Non-intelligent behaviour on device delete with multiple devices?
Hi Today I tried removing two devices from a multidevice btrfs RAID10 volume using the following command: --- btrfs device delete /dev/sdl /dev/sdk /btrfs --- It first removed device sdl and then sdk. What I did not expect however was that btrfs didn't remove sdk from the available drives when removing and rebalancing data from the first device. This resultated in that over 300GB of data was actually added to sdk during removal of sdl, only to make the removal process of sdk longer. This seems to me as a rather non-intelligent way to do this. I would expect that all drives given as input to the btrfs device delete command was removed from the list of drives available for rebalancing of the data during removal of the drives. Regards, Hans-Kristian Bakke -- 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 unable to mount
Ehm, after one, or two days (computer was shut down normally to night), now I am not able to mount that btrfs partition. Nor btrfs-zero-log helps. I am going to reformat it, but uploading btrfs-image for further analyse if anybody wants. PS: I have used for this btrfs partition a bcache partition. Bcache block device consists of iscsi drive (140GB) as a backing device and one ssd partition (20GB) used as a cache device. This is possibly a couse of these problems. I will try ext3 now for that partition. - lu...@plaintext.sk wrote: Hi I have similar (not same) problem like described here: http://www.spinics.net/lists/linux-btrfs/msg27102.html So I want just make Josef to have some fun seeing btrfs-image of unmountable filesystem, before btrfs-zero-log command... Two images and explanatory text is available on here: http://dawn.ynet.sk/~luvar/asdf/btrfs/ File btrfs.unabletomount contains explanatory text. image files are beeing uploaded right now and will be there in a few minutes. If any additional question, just ask. LuVar -- 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
Total fs size does not match with the actual size of the setup
The btrfs setup only have one device of size 7 GiB but when I run df, the total size shown is 15 GiB. Running btrfs --repair displays an error cache and super generation don't match, space cache will be invalidated. How can I correct the total fs size as shown in df? -- 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: Total fs size does not match with the actual size of the setup
On Mon, Oct 28, 2013 at 04:09:18AM +0800, Lester B wrote: The btrfs setup only have one device of size 7 GiB but when I run df, the total size shown is 15 GiB. Running btrfs --repair I'd recommend not running btrfs check --repair unless you really know what you're doing, or you've checked with someone knowledgable and they say you should try it. On a non-broken filesystem (as here), it's probably OK, though. displays an error cache and super generation don't match, space cache will be invalidated. This is harmless. How can I correct the total fs size as shown in df? You can't. It's an artefact of the fact that you've got a RAID-1 (or RAID-10, or --mixed and DUP) filesystem, and that the standard kernel interface for df doesn't allow us to report the correct figures -- see [1] (and the subsequent entry as well) for a more detailed description. Hugo. [1] https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- === 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 --- Nothing right in my left brain. Nothing left in --- my right brain. signature.asc Description: Digital signature
Re: Total fs size does not match with the actual size of the setup
2013/10/28 Hugo Mills h...@carfax.org.uk: On Mon, Oct 28, 2013 at 04:09:18AM +0800, Lester B wrote: The btrfs setup only have one device of size 7 GiB but when I run df, the total size shown is 15 GiB. Running btrfs --repair I'd recommend not running btrfs check --repair unless you really know what you're doing, or you've checked with someone knowledgable and they say you should try it. On a non-broken filesystem (as here), it's probably OK, though. displays an error cache and super generation don't match, space cache will be invalidated. This is harmless. How can I correct the total fs size as shown in df? You can't. It's an artefact of the fact that you've got a RAID-1 (or RAID-10, or --mixed and DUP) filesystem, and that the standard kernel interface for df doesn't allow us to report the correct figures -- see [1] (and the subsequent entry as well) for a more detailed description. Hugo. [1] https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- === 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 --- Nothing right in my left brain. Nothing left in --- my right brain. But my setup is a simple one without any RAID levels or other things so at least df size column should show the actual size of my setup. -- 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: 3.11 and 3.12rc continual hard lock ups
OK, hard another crash this afternoon - I had dmesg -n7 set and this time (unusually) I had something in the logs: Oct 27 14:48:15 enterprise kernel: [23752.263442] INFO: task nfsd:1537 blocked for more than 120 seconds. Oct 27 14:48:15 enterprise kernel: [23752.263452] Not tainted 3.12.0-999-generic #201310210405 Oct 27 14:48:21 enterprise kernel: [23752.263460] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Oct 27 14:48:21 enterprise kernel: [23752.263469] nfsdD 0 1537 2 0x Oct 27 14:48:21 enterprise kernel: [23752.263484] 8800ba29db38 0046 880036bcc1a0 88003602b800 Oct 27 14:48:21 enterprise kernel: [23752.263503] 8800ba29dfd8 8800ba29dfd8 8800ba29dfd8 000144c0 Oct 27 14:48:21 enterprise kernel: [23752.263513] 880329daaf60 8800ba1a17b0 8800ba29db48 88032b893430 Oct 27 14:48:21 enterprise kernel: [23752.263523] Call Trace: Oct 27 14:48:21 enterprise kernel: [23752.263531] [81744d79] schedule+0x29/0x70 Oct 27 14:48:21 enterprise kernel: [23752.263557] [a01642f1] wait_current_trans.isra.33+0xc1/0x120 [btrfs] Oct 27 14:48:21 enterprise kernel: [23752.263566] [8108cc40] ? add_wait_queue+0x60/0x60 Oct 27 14:48:21 enterprise kernel: [23752.263580] [a016615e] start_transaction.part.35+0x2ee/0x510 [btrfs] Oct 27 14:48:21 enterprise kernel: [23752.263594] [a01663a9] start_transaction+0x29/0x30 [btrfs] Oct 27 14:48:21 enterprise kernel: [23752.263607] [a01665fb] btrfs_start_transaction+0x1b/0x20 [btrfs] Oct 27 14:48:21 enterprise kernel: [23752.263622] [a01744b6] btrfs_create+0x46/0x220 [btrfs] Oct 27 14:48:21 enterprise kernel: [23752.263628] [812fb7fc] ? security_inode_permission+0x1c/0x30 Oct 27 14:48:21 enterprise kernel: [23752.263634] [811cc0b5] vfs_create+0xb5/0x120 Oct 27 14:48:21 enterprise kernel: [23752.263643] [a065941c] do_nfsd_create+0x50c/0x5f0 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263653] [a06608ad] nfsd3_proc_create+0x16d/0x250 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263660] [a0651d65] nfsd_dispatch+0xe5/0x230 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263673] [a05dbf55] svc_process_common+0x345/0x680 [sunrpc] Oct 27 14:48:21 enterprise kernel: [23752.263685] [a05dc5e3] svc_process+0x103/0x160 [sunrpc] Oct 27 14:48:21 enterprise kernel: [23752.263692] [a06518cf] nfsd+0xbf/0x130 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263699] [a0651810] ? nfsd_destroy+0x80/0x80 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263704] [8108c0e0] kthread+0xc0/0xd0 Oct 27 14:48:21 enterprise kernel: [23752.263709] [8108c020] ? flush_kthread_worker+0xb0/0xb0 Oct 27 14:48:21 enterprise kernel: [23752.263715] [8174f6fc] ret_from_fork+0x7c/0xb0 Oct 27 14:48:21 enterprise kernel: [23752.263720] [8108c020] ? flush_kthread_worker+0xb0/0xb0 Oct 27 14:48:21 enterprise kernel: [23752.263725] INFO: task nfsd:1539 blocked for more than 120 seconds. Oct 27 14:48:21 enterprise kernel: [23752.263729] Not tainted 3.12.0-999-generic #201310210405 Oct 27 14:48:21 enterprise kernel: [23752.263733] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Oct 27 14:48:21 enterprise kernel: [23752.263737] nfsdD 0 1539 2 0x Oct 27 14:48:21 enterprise kernel: [23752.263744] 88032d783c38 0046 88032d783be8 81094340 Oct 27 14:48:21 enterprise kernel: [23752.263753] 88032d783fd8 88032d783fd8 88032d783fd8 000144c0 Oct 27 14:48:21 enterprise kernel: [23752.263764] 88032e5ddec0 8800ba1a4710 88032d783c18 8802f2573408 Oct 27 14:48:21 enterprise kernel: [23752.263773] Call Trace: Oct 27 14:48:21 enterprise kernel: [23752.263778] [81094340] ? set_groups+0x40/0x60 Oct 27 14:48:21 enterprise kernel: [23752.263783] [81744d79] schedule+0x29/0x70 Oct 27 14:48:21 enterprise kernel: [23752.263788] [8174509e] schedule_preempt_disabled+0xe/0x10 Oct 27 14:48:21 enterprise kernel: [23752.263794] [81743024] __mutex_lock_slowpath+0x114/0x1b0 Oct 27 14:48:21 enterprise kernel: [23752.263800] [817430e3] mutex_lock+0x23/0x40 Oct 27 14:48:21 enterprise kernel: [23752.263807] [a0659088] do_nfsd_create+0x178/0x5f0 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263816] [a06608ad] nfsd3_proc_create+0x16d/0x250 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263824] [a0651d65] nfsd_dispatch+0xe5/0x230 [nfsd] Oct 27 14:48:21 enterprise kernel: [23752.263835] [a05dbf55] svc_process_common+0x345/0x680 [sunrpc] Oct 27 14:48:21 enterprise kernel: [23752.263846] [a05dc5e3] svc_process+0x103/0x160 [sunrpc] Oct 27 14:48:21 enterprise kernel: [23752.263853] [a06518cf] nfsd+0xbf/0x130 [nfsd] Oct 27 14:48:21 enterprise kernel:
Re: Non-intelligent behaviour on device delete with multiple devices?
On 2013/10/27 07:33 PM, Hans-Kristian Bakke wrote: Hi Today I tried removing two devices from a multidevice btrfs RAID10 volume using the following command: --- btrfs device delete /dev/sdl /dev/sdk /btrfs --- It first removed device sdl and then sdk. What I did not expect however was that btrfs didn't remove sdk from the available drives when removing and rebalancing data from the first device. This resultated in that over 300GB of data was actually added to sdk during removal of sdl, only to make the removal process of sdk longer. This seems to me as a rather non-intelligent way to do this. I would expect that all drives given as input to the btrfs device delete command was removed from the list of drives available for rebalancing of the data during removal of the drives. This is a known issue I'm sure will be addressed. It has annoyed me in the past as well. Perhaps add it to the wiki: https://btrfs.wiki.kernel.org/index.php/Project_ideas -- __ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97 -- 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: Total fs size does not match with the actual size of the setup
On 2013/10/27 10:27 PM, Lester B wrote: 2013/10/28 Hugo Mills h...@carfax.org.uk: On Mon, Oct 28, 2013 at 04:09:18AM +0800, Lester B wrote: The btrfs setup only have one device of size 7 GiB but when I run df, the total size shown is 15 GiB. Running btrfs --repair I'd recommend not running btrfs check --repair unless you really know what you're doing, or you've checked with someone knowledgable and they say you should try it. On a non-broken filesystem (as here), it's probably OK, though. displays an error cache and super generation don't match, space cache will be invalidated. This is harmless. How can I correct the total fs size as shown in df? You can't. It's an artefact of the fact that you've got a RAID-1 (or RAID-10, or --mixed and DUP) filesystem, and that the standard kernel interface for df doesn't allow us to report the correct figures -- see [1] (and the subsequent entry as well) for a more detailed description. Hugo. [1] https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- === 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 --- Nothing right in my left brain. Nothing left in --- my right brain. But my setup is a simple one without any RAID levels or other things so at least df size column should show the actual size of my setup. Could you send us the output of the following?: btrfs fi df mountpoint (where mountpoint is the path where the btrfs is mounted.) -- __ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97 -- 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: Total fs size does not match with the actual size of the setup
sudo btrfs fi df mountpoint Data: total=5.62GB, used=4.96GB System: total=32.00MB, used=4.00KB Metadata: total=512.00MB, used=288.70MB -- 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, problem
I made some more tests. Disk is 3TB, first cca 225GB is copied without errors. Then errors 'No space left on device' begins. Now if I use rsync with '--bwlimit' option no error occurs or if I choose 'Retry' in Midnight Commander then continues and after a while another error occurs and again 'Retry' and so on. I also noticed something else. Just before this error occurs, write() call takes a lot longer, I also see that progress stops. If I do 'btrfs fi df ..' at this moment: Data: total=114.01GB, used=112.00GB System, DUP: total=8.00MB, used=20.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=452.93MB Metadata: total=8.00MB, used=0.00 then error is reported, again 'btrfs fi df ..' Data: total=114.01GB, used=113.00GB System, DUP: total=8.00MB, used=20.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=456.98MB Metadata: total=8.00MB, used=0.00 and then 'Retry' and it goes on, until another error. Always before error, copying stops and used Data and Metadata changes. Maybe it's something with allocating metadata. I don't know. This goes on for cca 25G-30G and from now on no errors anymore. After this 1.3TB was copied without errors. But some of data was on rather slow disk, so maybe that's why no more errors. On Sun, Oct 27, 2013 at 9:50 AM, Igor M igor...@gmail.com wrote: On Sun, Oct 27, 2013 at 2:00 AM, Tomasz Chmielewski t...@virtall.com wrote: Still no messages. Parameter seems to be active as /sys/module/printk/parameters/ignore_loglevel is Y, but there are no messages in log files or dmesg. Maybe I need to turn on some kernel debugging option and recompile kernel ? Also I should mention that cca 230G+ data was copied before this error started to occur. I think I saw a similar issue before. Can you try using rsync with --bwlimit XY option to copy the files? The option will limit the speed, in kB, at which the file is being copied; it will work even when source and destination files are on a local machine. Also I run strace cp -a .. ... read(3, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 write(4, 350348f07$0$24520$c3e8da3$fb4835..., 65536) = 65536 read(3, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = 65536 write(4, 62.76C52BF412E849CB86D4FF3898B94..., 65536) = -1 ENOSPC (No space left on device) Last two write calls take a lot more time, and then last one returns ENOSPC. But if this write is retryed, then it succeeds. I tried with midnight commander and when error occurs, if I Retry operation then it finishes copying this file until error occurs again at next file. With --bwlimit it seems to be better, lower the speed later the error occurs, and if it's slow enough copy is successfull. But now I'm not sure anymore. I copied a few files with bwlimit, and now sudenly error doesn't occur anymore, even with no bwlimit. I'll do some more tests. -- 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, problem
On Oct 27, 2013, at 3:53 PM, Igor M igor...@gmail.com wrote: I made some more tests. Disk is 3TB, first cca 225GB is copied without errors. Then errors 'No space left on device' begins. Post the full entire dmesg somewhere please. pastebin.com is one option. Chris Murphy-- 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
Error from Trying to Mount Btrfs
I have the attached error from trying to mount btrfs on external hard drive. The F.S. was my primary system, then I dd'd it to an external and reinstalled Fedora. I tried to follow https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#Filesystem_can.27t_be_mounted_by_label. I used # btrfs device scan --all-devices before attempting to mount. What should I do? Appreciatively, Gatlin. P.S. This file system is very important to me becasue it has a large collection of songs. attachment: ErrorMessage.pngError mounting /dev/sdb3 at /run/media/gatlibs/fedora: Command-line `mount -t btrfs -o uhelper=udisks2,nodev,nosuid /dev/sdb3 /run/media/gatlibs/fedora' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sdb3, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. [root@dell-studio-1555 ~]# mount -t btrfs -o recovery /dev/sdb3 /run/media/gatlibs/fedora mount: wrong fs type, bad option, bad superblock on /dev/sdb3, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. [root@dell-studio-1555 ~]# dmesg | tail [ 1773.320077] btrfs: open_ctree failed [ 1800.704035] mce: [Hardware Error]: Machine check events logged [ 1969.644418] CPU0: Core temperature above threshold, cpu clock throttled (total events = 42644) [ 1969.645068] CPU0: Core temperature/speed normal [ 1979.367137] device label fedora devid 1 transid 115316 /dev/sdb3 [ 1979.369388] btrfs: superblock checksum mismatch [ 1979.374137] btrfs: open_ctree failed [ 2145.217088] device label fedora devid 1 transid 115316 /dev/sdb3 [ 2145.229732] btrfs: superblock checksum mismatch [ 2145.234772] btrfs: open_ctree failed
Re: No space left on device, problem
On Oct 27, 2013, at 4:46 PM, Chris Murphy li...@colorremedies.com wrote: On Oct 27, 2013, at 3:53 PM, Igor M igor...@gmail.com wrote: I made some more tests. Disk is 3TB, first cca 225GB is copied without errors. Then errors 'No space left on device' begins. Post the full entire dmesg somewhere please. pastebin.com is one option. And on list or pasted, the output for the disk from: smartctl -x /dev/sdX Chris Murphy-- 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
