Re: mount a multi-device filesystem using a loopback device

2011-09-07 Thread Jeff Liu 


On 09/07/2011 02:31 PM, Li Zefan wrote:

Is it a bug? or Am I missing something?


You need to run this before mounting the devices:

   # btrfs device scan

Thank you, it works by executing device scan.

-Jeff
--
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: Problems with tuxonice and btrfs

2011-09-07 Thread David Sterba 
On Sun, Sep 04, 2011 at 04:23:20PM +0100, Maciej Marcin Piechotka wrote:
 I get filesystem corruption when I unsuccessfully hibernate using
 tuxonice. I don't get this problem using standard suspend.

Just a guess and general thought, I've never used TOI. There is probably
some activity inside the filesystem going on and is not properly
stopped, like in the standard suspend case. I'd start at TOI verifying
that it follows the steps during freezing and unfreezing the filesystem,
as does standard suspend.

 While I understand TOI is not in mainline it requires no modification
 for non-FUSE filesystems. where should I report the problem?

This does not seem to be a genuine btrfs bug, rather some misinteraction
with TOI.


david
--
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: calc file extent num_bytes correctly in file clone

2011-09-07 Thread David Sterba 
minor, typos in comments s/substract/subtract/

On Wed, Aug 24, 2011 at 02:13:16PM +0800, Li Zefan wrote:
 diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
 index 660a6c8..3351b1b 100644
 --- a/fs/btrfs/ioctl.c
 +++ b/fs/btrfs/ioctl.c
 @@ -2331,14 +2331,21 @@ static noinline long btrfs_ioctl_clone(struct file 
 *file, unsigned long srcfd,
  
   if (type == BTRFS_FILE_EXTENT_REG ||
   type == BTRFS_FILE_EXTENT_PREALLOC) {
 + /*
 +  *a  | --- range to clone ---|  b
 +  * | - extent - |
 +  */
 +
 + /* substract range b */
...

 + if (key.offset + datal  off + len)
 + datal = off + len - key.offset;
 +
 + /* substract range a */
...

   if (off  key.offset) {
   datao += off - key.offset;
   datal -= off - key.offset;
   }
  
 - if (key.offset + datal  off + len)
 - datal = off + len - key.offset;
 -
   ret = btrfs_drop_extents(trans, inode,
new_key.offset,
new_key.offset + datal,
--
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: fix warning in iput for bad-inode

2011-09-07 Thread David Sterba 
On Fri, Sep 02, 2011 at 08:01:21PM +0300, sly...@gmail.com wrote:
 From: Sergei Trofimovich sly...@gentoo.org
 
 iput() shouldn't be called for inodes in I_NEW state.
 We need to mark inode as constructed first.
 
 WARNING: at fs/inode.c:1309 iput+0x20b/0x210()
 Call Trace:
  [8103e7ba] warn_slowpath_common+0x7a/0xb0
  [8103e805] warn_slowpath_null+0x15/0x20
  [810eaf0b] iput+0x20b/0x210
  [811b96fb] btrfs_iget+0x1eb/0x4a0
  [811c3ad6] btrfs_run_defrag_inodes+0x136/0x210
  [811ad55f] cleaner_kthread+0x17f/0x1a0
  [81035b7d] ? sub_preempt_count+0x9d/0xd0
  [811ad3e0] ? transaction_kthread+0x280/0x280
  [8105af86] kthread+0x96/0xa0
  [814336d4] kernel_thread_helper+0x4/0x10
  [8105aef0] ? kthread_worker_fn+0x190/0x190
  [814336d0] ? gs_change+0xb/0xb
 
 Signed-off-by: Sergei Trofimovich sly...@gentoo.org
 CC: Konstantin Khlebnikov khlebni...@openvz.org

Tested-by: David Sterba dste...@suse.cz

 ---
 Change since Konstantin's patch:
 - avoid using explicit destructor for inode, as it can(?)
   be shared among other threads. Use unlock_new_inode()/iput()
   instead. It fixes 100% CPU load after 'sync()' popped-up in
   Konstantin's patch
  fs/btrfs/inode.c |   10 +++---
  1 files changed, 3 insertions(+), 7 deletions(-)
 
 diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
 index 0ccc743..ec4b550 100644
 --- a/fs/btrfs/inode.c
 +++ b/fs/btrfs/inode.c
 @@ -3952,7 +3952,6 @@ struct inode *btrfs_iget(struct super_block *s, struct 
 btrfs_key *location,
struct btrfs_root *root, int *new)
  {
   struct inode *inode;
 - int bad_inode = 0;
  
   inode = btrfs_iget_locked(s, location-objectid, root);
   if (!inode)
 @@ -3968,15 +3967,12 @@ struct inode *btrfs_iget(struct super_block *s, 
 struct btrfs_key *location,
   if (new)
   *new = 1;
   } else {
 - bad_inode = 1;
 + unlock_new_inode(inode);
 + iput(inode);
 + inode = ERR_PTR(-ESTALE);
   }
   }
  
 - if (bad_inode) {
 - iput(inode);
 - inode = ERR_PTR(-ESTALE);
 - }
 -
   return inode;
  }
  
 -- 
 1.7.3.4
 
 --
 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
--
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 a multi-device filesystem using a loopback device

2011-09-07 Thread Jeff Liu 

On 09/07/2011 12:37 PM, cwillu wrote:

1.  Create and format two images, the 1st in 400Mbytes, and 2nd in 286Mbytes.
root@pibroch:/btrfs-progs# ls -lh /usr/src/linux-3.0/img*
-rw-r--r-- 1 jeff jeff 400M 2011-09-07 12:00 /usr/src/linux-3.0/img0
-rw-r--r-- 1 jeff jeff 286M 2011-09-07 12:00 /usr/src/linux-3.0/img1

Very small btrfs filesystem require special handling, mixed block
groups in particular, which I believe also requires an updated mkfs
from the integration repo.
Thanks for your response, however, even if I enlarged the image size to 
2G, still got no luck.

Per Zefan's comments, run 'btrfs device scan' fixed this issue.

-Jeff

--
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


--
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: Problems with set-default, home subvolume and snapshot

2011-09-07 Thread Björn Kalkbrenner 
Hi,

Am 05.09.2011 14:45, schrieb Hugo Mills:

It'd be good if you have the time to try to reproduce this,
 particularly with the latest kernels (3.0 or 3.1-rcX)

My recovery is done. Here are some infos...

-
Linux-3.0.0-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_965_@_3.20GHz-with-gentoo-2.0.3
- Btrfs v0.19-35-g1b444cd-dirty

First, i did a mount, then i got the btrfs-bug kernel msg (see
attachment). When i tried to mount a second time, mount hung, maybe due
to the first btrfs bug kernel message stuff.

The btrfsck.txt is the output of the btrfsck i tried, i know that
doesn't fix anything yet.

Bye
Björn
device fsid b8ff0678-6466-4b4c-ab32-31108423ecfb devid 1 transid 32199 
/dev/mapper/sdh2
[ cut here ]
kernel BUG at fs/btrfs/inode.c:4586!
invalid opcode:  [#1] SMP 
CPU 6 
Modules linked in: hidp usbip_host(C) usbip_core(C) nfsd ipv6 bnep rfcomm 
hid_magicmouse cpufreq_ondemand acpi_cpufreq freq_table mperf tun vboxnetflt 
vboxdrv nvidia(P) snd_hda_codec_realtek snd_hda_intel btusb snd_hda_codec 
joydev bluetooth rfkill snd_hwdep snd_pcm snd_timer snd snd_page_alloc 
processor i2c_i801 e1000e i2c_core thermal_sys button pcspkr iscsi_tcp 
libiscsi_tcp libiscsi scsi_transport_iscsi tg3 libphy e1000 fuse nfs lockd 
sunrpc raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor 
async_tx raid6_pq raid1 raid0 dm_snapshot dm_crypt dm_mirror dm_region_hash 
dm_log dm_mod scsi_wait_scan hid_sunplus hid_sony hid_samsung hid_pl 
hid_petalynx hid_monterey hid_microsoft hid_logitech hid_gyration hid_ezkey 
hid_cypress hid_chicony hid_cherry hid_belkin hid_apple hid_a4tech sl811_hcd 
usbhid ohci_hcd ssb uhci_hcd usb_storage ehci_hcd usbcore lpfc qla2xxx 
megaraid_sas megaraid_mbox megaraid_mm megaraid sx8 DAC960 cciss mptsas mptfc 
scsi_transport_fc scsi_tgt mptspi mptscsih mptbase atp870u dc395x qla1280 imm 
parport dmx3191d sym53c8xx gdth advansys initio BusLogic arcmsr sg pdc_adma 
sata_inic162x sata_mv ata_piix ahci libahci sata_qstor sata_vsc sata_uli 
sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise 
pata_sl82c105 pata_cs5530 pata_cs5520 pata_via pata_jmicron pata_marvell 
pata_sis pata_netcell pata_sc1200 pata_pdc202xx_old pata_triflex pata_atiixp 
pata_opti pata_amd pata_ali pata_it8213 pata_pcmcia pcmcia pcmcia_core 
pata_ns87415 pata_ns87410 pata_serverworks pata_platform pata_artop pata_it821x 
pata_optidma pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x 
pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027x pata_mpiix libata

Pid: 23202, comm: mount Tainted: P C  3.0.0-gentoo #1  
/DX58SO
RIP: 0010:[812f313e]  [812f313e] 0x812f313e
RSP: 0018:8802ea5397c8  EFLAGS: 00010282
RAX: ffef RBX: 8802a9830a88 RCX: 880322236dd8
RDX: 000c RSI: 88013874b760 RDI: 880320c1c500
RBP: 8802ea539838 R08: 8802a9830a88 R09: 8800cecc7000
R10: 8802ea539600 R11: 8802ea5396a8 R12: 8802a9830678
R13: 8800cecc7000 R14: 000f R15: 88022666c700
FS:  7f3dbf849740() GS:88032fcc() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 7f3dbf1b0600 CR3: 0002ea73a000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process mount (pid: 23202, threadinfo 8802ea538000, task 88032e0b2c70)
Stack:
 88020001 58c9 8802ea5397f8 8802a982a540
 000751d8 0001 1000 
 880281e52000 8802a9830678 88013874b7f0 8802ea539988
Call Trace:
 [81316e02] 0x81316e02
 [813178dc] 0x813178dc
 [81315242] 0x81315242
 [813154e4] 0x813154e4
 [81316660] 0x81316660
 [8131769e] ? 0x8131769e
 [812e951a] 0x812e951a
 [812cbfc2] 0x812cbfc2
 [810a1a1b] ? 0x810a1a1b
 [8139e57c] ? 0x8139e57c
 [810b9c02] 0x810b9c02
 [810d0cf4] 0x810d0cf4
 [810d0d8a] 0x810d0d8a
 [810d14e2] 0x810d14e2
 [8109e193] ? 0x8109e193
 [8109e1eb] ? 0x8109e1eb
 [810d15c9] 0x810d15c9
 [8158697b] 0x8158697b
Code: 41 8b 04 24 44 89 f1 66 c1 e8 0c 4c 89 fa 0f b7 c0 4c 89 ee 0f b6 80 f0 
fa 5b 81 48 8b 7d a8 89 04 24 e8 a1 e8 fe ff 85 c0 74 04 0f 0b eb fe 45 01 f6 
4d 63 f6 4c 03 b3 d8 00 00 00 4c 89 b3 d8 
RIP  [812f313e] 0x812f313e
 RSP 8802ea5397c8
---[ end trace 8fa5393ebe82965d ]---
btrfsck /dev/mapper/sdh2 
root 256 inode 433544 errors 400
root 256 inode 433651 errors 400
root 256 inode 433652 errors 400
root 256 inode 433653 errors 400
root 256 inode 433657 errors 400
root 256 inode 433658 errors 400
root 256 inode 433659 errors 400
root

Btrfs moved my root tree off the end of the device

2011-09-07 Thread Justin Gottula 
Hi,


I recently created a Btrfs volume on top of a software (mdadm) raid5 array
(since Btrfs currently lacks raid5 support at the FS level). On this 640 GB
volume, I stored a ~400 GB tar file. After a couple weeks of use, I used 'btrfs
defragment' on this file in an effort to (a) defrag and (b) compress the file. I
made sure I was using the latest version of the userspace utilities (Btrfs
v0.19-35-g1b444cd-dirty) as well as kernel 3.0.

Now, this may or may not have had something to do with the drives being at 55
celsius, which I only discovered later, but after I had left this operation to
work overnight, I came back to some scary messages in the kernel log.
Immediately after the operation started (as far as I can tell), the following
messages showed up in the kernel log:


[17055.793912] btrfs: relocating block group 636489826304 flags 1

[17112.566998] attempt to access beyond end of device
[17112.567003] md127p1: rw=145, want=1248172032, limit=1248171999
[17112.567004] attempt to access beyond end of device
[17112.567006] md127p1: rw=145, want=1248172280, limit=1248171999
[17112.567008] attempt to access beyond end of device
[17112.567009] md127p1: rw=145, want=1248172416, limit=1248171999
[17112.567011] attempt to access beyond end of device
[17112.567012] md127p1: rw=145, want=1248172664, limit=1248171999
[17112.567014] attempt to access beyond end of device
[17112.567015] md127p1: rw=145, want=1248172912, limit=1248171999
[17112.567016] attempt to access beyond end of device
[17112.567018] md127p1: rw=145, want=1248172928, limit=1248171999
(thousands more of the above in rapid succession)


and occasionally a few of these:


[17157.916746] btrfs csum failed ino 258 off 8192 csum 2566472073 private
1679206033
[17157.916758] btrfs csum failed ino 258 off 12288 csum 2566472073 private
248979876
[17157.916771] btrfs csum failed ino 258 off 16384 csum 2566472073 private
3790022839


Then, later, another burst of the same device access warnings followed by this:


[20063.971837] [ cut here ]
[20063.972050] kernel BUG at fs/btrfs/ctree.c:300!
[20063.972238] invalid opcode:  [#1] PREEMPT SMP 
[20063.972666] CPU 0 
[20063.972669] Modules linked in: ipv6 loop nouveau snd_hda_codec_via ttm
drm_kms_helper drm r8169 forcedeth i2c_nforce2 mii ppdev i2c_algo_bit mxm_wmi
parport_pc wmi pcspkr video parport asus_atk0110 snd_hda_intel evdev sg
edac_core edac_mce_amd snd_hda_codec processor psmouse button snd_hwdep snd_pcm
snd_timer snd soundcore snd_page_alloc k10temp serio_raw i2c_core usbhid hid
raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
raid0 btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 ohci_hcd
ehci_hcd usbcore md_mod sata_nv sd_mod pata_amd libata scsi_mod
[20063.974670] 
[20063.974670] Pid: 7425, comm: btrfs-endio-wri Not tainted 3.0-ARCH #1 System
manufacturer System Product Name/M4N68T-M-V2
[20063.974670] RIP: 0010:[a01a1df1]  [a01a1df1]
update_ref_for_cow+0x331/0x340 [btrfs]
[20063.974670] RSP: 0018:8800236798b0  EFLAGS: 00010282
[20063.974670] RAX: fffb RBX: 88002539f000 RCX: 0001bc22b580
[20063.974670] RDX: 0001bc22b540 RSI: 60ffc24024f0 RDI: eacb7930
[20063.974670] RBP: 880023679900 R08: a01a121a R09: 
[20063.974670] R10: fffb R11: 0001 R12: 880020a72a00
[20063.974670] R13: 880037c7f000 R14: 88002c24fc00 R15: 88002367997c
[20063.974670] FS:  7f6c7ea81740() GS:88003d80()
knlGS:
[20063.974670] CS:  0010 DS:  ES:  CR0: 8005003b
[20063.974670] CR2: 7fe40de62000 CR3: 25978000 CR4: 06f0
[20063.974670] DR0:  DR1:  DR2: 
[20063.974670] DR3:  DR6: 0ff0 DR7: 0400
[20063.974670] Process btrfs-endio-wri (pid: 7425, threadinfo 880023678000,
task 88003a43f300)
[20063.974670] Stack:
[20063.974670]  1000 880023678000 880023679fd8
880025cb8010
[20063.974670]  880023679910 88002539f000 88002c24fc00
880020a72a00
[20063.974670]  880037c7f000 880003955900 8800236799b0
a01a2276
[20063.974670] Call Trace:
[20063.974670]  [a01a2276] __btrfs_cow_block+0x476/0x890 [btrfs]
[20063.974670]  [a01a27a8] btrfs_cow_block+0x118/0x360 [btrfs]
[20063.974670]  [a01a7e0e] btrfs_search_slot+0x1de/0x900 [btrfs]
[20063.974670]  [a01bac58] btrfs_lookup_file_extent+0x38/0x40 [btrfs]
[20063.974670]  [a01d54c4] btrfs_drop_extents+0x104/0xa10 [btrfs]
[20063.974670]  [a01cadf3]
insert_reserved_file_extent.constprop.47+0x73/0x250 [btrfs]
[20063.974670]  [a01c6007] ? start_transaction+0x97/0x2b0 [btrfs]
[20063.974670]  [a01cbf9a] btrfs_finish_ordered_io+0x2da/0x320 [btrfs]
[20063.974670]  [a01cc02d] btrfs_writepage_end_io_hook+0x4d/0xf0
[btrfs]

[PATCH] Btrfs: remove BUG_ON() in compress_file_range()

2011-09-07 Thread Li Zefan 
It's not a big deal if we fail to allocate the array, and instead of
panic we can just give up compressing.

Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
 fs/btrfs/inode.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 0ccc743..63b4fc0 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -393,7 +393,10 @@ again:
 (BTRFS_I(inode)-flags  BTRFS_INODE_COMPRESS))) {
WARN_ON(pages);
pages = kzalloc(sizeof(struct page *) * nr_pages, GFP_NOFS);
-   BUG_ON(!pages);
+   if (!pages) {
+   /* just bail out to the uncompressed code */
+   goto cont;
+   }
 
if (BTRFS_I(inode)-force_compress)
compress_type = BTRFS_I(inode)-force_compress;
@@ -424,6 +427,7 @@ again:
will_compress = 1;
}
}
+cont:
if (start == 0) {
trans = btrfs_join_transaction(root);
BUG_ON(IS_ERR(trans));
-- 1.7.3.1 
--
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

[PATCH] Btrfs: fix direct-io vs nodatacow

2011-09-07 Thread Li Zefan 
To reproduce the bug:

  # mount -o nodatacow /dev/sda7 /mnt/
  # dd if=/dev/zero of=/mnt/tmp bs=4K count=1
  1+0 records in
  1+0 records out
  4096 bytes (4.1 kB) copied, 0.000136115 s, 30.1 MB/s
  # dd if=/dev/zero of=/mnt/tmp bs=4K count=1 conv=notrunc oflag=direct
  dd: writing `/mnt/tmp': Input/output error
  1+0 records in
  0+0 records out

btrfs_ordered_update_i_size() may return 1, but btrfs_endio_direct_write()
mistakenly takes it as an error.

Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
 fs/btrfs/inode.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 0ccc743..3bd35fe 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5785,8 +5785,7 @@ again:
if (test_bit(BTRFS_ORDERED_NOCOW, ordered-flags)) {
ret = btrfs_ordered_update_i_size(inode, 0, ordered);
if (!ret)
-   ret = btrfs_update_inode(trans, root, inode);
-   err = ret;
+   err = btrfs_update_inode(trans, root, inode);
goto out;
}
 
-- 1.7.3.1 
--
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 moved my root tree off the end of the device

2011-09-07 Thread C Anthony Risinger 
On Wed, Sep 7, 2011 at 6:33 PM, Justin Gottula jus...@jgottula.com wrote:

 Hi,

 I recently created a Btrfs volume on top of a software (mdadm) raid5 array
 (since Btrfs currently lacks raid5 support at the FS level). On this 640 GB
 volume, I stored a ~400 GB tar file. After a couple weeks of use, I used 
 'btrfs
 defragment' on this file in an effort to (a) defrag and (b) compress the 
 file. I
 made sure I was using the latest version of the userspace utilities (Btrfs
 v0.19-35-g1b444cd-dirty) as well as kernel 3.0.

did you use the integration branch, ie:

http://git.darksatanic.net/repo/btrfs-progs-unstable.git

... this has the latest code for the time being.  looks like
`integration-20110805` is the most recent head.

 snip

 At this point, I took a disk image and dived in, and in doing so discovered 
 that
 somehow, there were CHUNK_ITEMs in the chunk tree that referred to physical
 address ranges that were entirely outside of the device (matching up to the
 ranges showing up in the kernel log over and over). Evidently, the filesystem
 driver thought it should move the root tree onto a chunk that existed at a
 nonexistant offset in the device. I checked the superblocks and verified that
 the total_bytes fields matched up correctly to the actual device size, which
 leaves me wondering how those chunks ever got there.

i could be way of base here, but your report reminded me of:

[thread] http://www.spinics.net/lists/linux-btrfs/index.html#12121

---
extent data backref root 5 objectid 258 offset 18446744073709543424 count 1
extent data backref root 5 objectid 257 offset 0 count 1

 So I think we have to live with this defect, just fix relocation for
 the negative offset case ?

I prefer fixing relocation.
---

... which, if i understood correctly, surfaced some issues with
relocation that could cause the offset to be grossly inaccurate (eg.
off the device completely?)

could of course be completely unrelated :-)

-- 

C Anthony
--
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 a multi-device filesystem using a loopback device

2011-09-07 Thread C Anthony Risinger 
On Wed, Sep 7, 2011 at 1:44 AM, Jeff Liu jeff@oracle.com wrote:
 On 09/07/2011 12:37 PM, cwillu wrote:

 1.  Create and format two images, the 1st in 400Mbytes, and 2nd in
 286Mbytes.
 root@pibroch:/btrfs-progs# ls -lh /usr/src/linux-3.0/img*
 -rw-r--r-- 1 jeff jeff 400M 2011-09-07 12:00 /usr/src/linux-3.0/img0
 -rw-r--r-- 1 jeff jeff 286M 2011-09-07 12:00 /usr/src/linux-3.0/img1

 Very small btrfs filesystem require special handling, mixed block
 groups in particular, which I believe also requires an updated mkfs
 from the integration repo.

 Thanks for your response, however, even if I enlarged the image size to 2G,
 still got no luck.
 Per Zefan's comments, run 'btrfs device scan' fixed this issue.

you should be able to achieve this via `device=` mount option(s?) as well:

https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options

... for completeness :-) ... and posterity or whatever.

C Anthony
--
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 moved my root tree off the end of the device

2011-09-07 Thread Arne Jansen 
On 08.09.2011 01:33, Justin Gottula wrote:
 Hi,
 
 
 I recently created a Btrfs volume on top of a software (mdadm) raid5 array
 (since Btrfs currently lacks raid5 support at the FS level). On this 640 GB
 volume, I stored a ~400 GB tar file. After a couple weeks of use, I used 
 'btrfs
 defragment' on this file in an effort to (a) defrag and (b) compress the 
 file. I
 made sure I was using the latest version of the userspace utilities (Btrfs
 v0.19-35-g1b444cd-dirty) as well as kernel 3.0.

I think Liu Bo posted a fix for this a while ago:

[PATCH] Btrfs: fix a bug of balance on full multi-disk partitions

-Arne

 Now, this may or may not have had something to do with the drives being at 55
 celsius, which I only discovered later, but after I had left this operation to
 work overnight, I came back to some scary messages in the kernel log.
 Immediately after the operation started (as far as I can tell), the following
 messages showed up in the kernel log:
 
 
 [17055.793912] btrfs: relocating block group 636489826304 flags 1
 
 [17112.566998] attempt to access beyond end of device
 [17112.567003] md127p1: rw=145, want=1248172032, limit=1248171999
 [17112.567004] attempt to access beyond end of device
 [17112.567006] md127p1: rw=145, want=1248172280, limit=1248171999
 [17112.567008] attempt to access beyond end of device
 [17112.567009] md127p1: rw=145, want=1248172416, limit=1248171999
 [17112.567011] attempt to access beyond end of device
 [17112.567012] md127p1: rw=145, want=1248172664, limit=1248171999
 [17112.567014] attempt to access beyond end of device
 [17112.567015] md127p1: rw=145, want=1248172912, limit=1248171999
 [17112.567016] attempt to access beyond end of device
 [17112.567018] md127p1: rw=145, want=1248172928, limit=1248171999
 (thousands more of the above in rapid succession)
 
 
 and occasionally a few of these:
 
 
 [17157.916746] btrfs csum failed ino 258 off 8192 csum 2566472073 private
 1679206033
 [17157.916758] btrfs csum failed ino 258 off 12288 csum 2566472073 private
 248979876
 [17157.916771] btrfs csum failed ino 258 off 16384 csum 2566472073 private
 3790022839
 
 
 Then, later, another burst of the same device access warnings followed by 
 this:
 
 
 [20063.971837] [ cut here ]
 [20063.972050] kernel BUG at fs/btrfs/ctree.c:300!
 [20063.972238] invalid opcode:  [#1] PREEMPT SMP 
 [20063.972666] CPU 0 
 [20063.972669] Modules linked in: ipv6 loop nouveau snd_hda_codec_via ttm
 drm_kms_helper drm r8169 forcedeth i2c_nforce2 mii ppdev i2c_algo_bit mxm_wmi
 parport_pc wmi pcspkr video parport asus_atk0110 snd_hda_intel evdev sg
 edac_core edac_mce_amd snd_hda_codec processor psmouse button snd_hwdep 
 snd_pcm
 snd_timer snd soundcore snd_page_alloc k10temp serio_raw i2c_core usbhid hid
 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy 
 async_tx
 raid0 btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 ohci_hcd
 ehci_hcd usbcore md_mod sata_nv sd_mod pata_amd libata scsi_mod
 [20063.974670] 
 [20063.974670] Pid: 7425, comm: btrfs-endio-wri Not tainted 3.0-ARCH #1 System
 manufacturer System Product Name/M4N68T-M-V2
 [20063.974670] RIP: 0010:[a01a1df1]  [a01a1df1]
 update_ref_for_cow+0x331/0x340 [btrfs]
 [20063.974670] RSP: 0018:8800236798b0  EFLAGS: 00010282
 [20063.974670] RAX: fffb RBX: 88002539f000 RCX: 
 0001bc22b580
 [20063.974670] RDX: 0001bc22b540 RSI: 60ffc24024f0 RDI: 
 eacb7930
 [20063.974670] RBP: 880023679900 R08: a01a121a R09: 
 
 [20063.974670] R10: fffb R11: 0001 R12: 
 880020a72a00
 [20063.974670] R13: 880037c7f000 R14: 88002c24fc00 R15: 
 88002367997c
 [20063.974670] FS:  7f6c7ea81740() GS:88003d80()
 knlGS:
 [20063.974670] CS:  0010 DS:  ES:  CR0: 8005003b
 [20063.974670] CR2: 7fe40de62000 CR3: 25978000 CR4: 
 06f0
 [20063.974670] DR0:  DR1:  DR2: 
 
 [20063.974670] DR3:  DR6: 0ff0 DR7: 
 0400
 [20063.974670] Process btrfs-endio-wri (pid: 7425, threadinfo 
 880023678000,
 task 88003a43f300)
 [20063.974670] Stack:
 [20063.974670]  1000 880023678000 880023679fd8
 880025cb8010
 [20063.974670]  880023679910 88002539f000 88002c24fc00
 880020a72a00
 [20063.974670]  880037c7f000 880003955900 8800236799b0
 a01a2276
 [20063.974670] Call Trace:
 [20063.974670]  [a01a2276] __btrfs_cow_block+0x476/0x890 [btrfs]
 [20063.974670]  [a01a27a8] btrfs_cow_block+0x118/0x360 [btrfs]
 [20063.974670]  [a01a7e0e] btrfs_search_slot+0x1de/0x900 [btrfs]
 [20063.974670]  [a01bac58] btrfs_lookup_file_extent+0x38/0x40 
 [btrfs]
 [20063.974670]  [a01d54c4] btrfs_drop_extents+0x104/0xa10 [btrfs]
 [20063.974670]  [a01cadf3]