Re: [PATCH 2/2] xfstests: meet btrfs fs size requirement in _scratch_mkfs_sized()
On Fri, Nov 4, 2011 at 1:39 PM, Christoph Hellwig wrote: > On Fri, Nov 04, 2011 at 10:38:04AM +0800, Eryu Guan wrote: >> btrfs requires at least 256M file system size, so check 'fssize' in >> _scratch_mkfs_sized first and give it a proper value. Otherwise >> mkfs.btrfs will complain something like >> >> "File system size 267386880 bytes is too small, 256M is required at least" >> >> This makes 015 077 and 083 run on btrfs. > > But it's not really going to test the ENOSPC conditions it was designed > to exercise. It would be better to either find a way to make btrfs run on > smaller filesystem, or call _notrun for too small filesystems on btrfs > from _scratch_mkfs_sized. Yes, you're right. I checked 015 (it would dd zero to btrfs to full) but forgot to check 077 and 083. I'll try to find a better way. Thanks for reviewing! Eryu Guan > >> >> Signed-off-by: Eryu Guan >> --- >> common.rc | 5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/common.rc b/common.rc >> index e948169..ab61786 100644 >> --- a/common.rc >> +++ b/common.rc >> @@ -356,6 +356,11 @@ _scratch_mkfs_sized() >> /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks >> ;; >> btrfs) >> + # btrfs needs at least 256M file system size >> + if [ $fssize -lt $((256*1024*1024)) ] >> + then >> + fssize=$((256*1024*1024)) >> + fi >> $MKFS_BTRFS_PROG $MKFS_OPTIONS -b $fssize $SCRATCH_DEV >> ;; >> *) >> -- >> 1.7.7.1 >> >> ___ >> xfs mailing list >> x...@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > ---end quoted text--- > -- 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 2/2] xfstests: meet btrfs fs size requirement in _scratch_mkfs_sized()
On Fri, Nov 04, 2011 at 10:38:04AM +0800, Eryu Guan wrote: > btrfs requires at least 256M file system size, so check 'fssize' in > _scratch_mkfs_sized first and give it a proper value. Otherwise > mkfs.btrfs will complain something like > > "File system size 267386880 bytes is too small, 256M is required at least" > > This makes 015 077 and 083 run on btrfs. But it's not really going to test the ENOSPC conditions it was designed to exercise. It would be better to either find a way to make btrfs run on smaller filesystem, or call _notrun for too small filesystems on btrfs from _scratch_mkfs_sized. > > Signed-off-by: Eryu Guan > --- > common.rc |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/common.rc b/common.rc > index e948169..ab61786 100644 > --- a/common.rc > +++ b/common.rc > @@ -356,6 +356,11 @@ _scratch_mkfs_sized() > /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks > ;; > btrfs) > +# btrfs needs at least 256M file system size > + if [ $fssize -lt $((256*1024*1024)) ] > + then > + fssize=$((256*1024*1024)) > + fi > $MKFS_BTRFS_PROG $MKFS_OPTIONS -b $fssize $SCRATCH_DEV > ;; > *) > -- > 1.7.7.1 > > ___ > xfs mailing list > x...@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs ---end quoted text--- -- 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: understanding the tree-log
On 11/04/2011 11:21 AM, Phillip Susi wrote: > Given how a transaction is committed, why is there a tree-log? When > modifying the tree, either the super block is still pointing to the > old tree root, or the new generation has been fully committed, so how > can there ever be an intermediate state that needs a log to recover? tree-log is for improving the preformance of fsync and and O_SYNCs. Btrfs has an expensive "commit transaction", if we commit a transaction every time we fsync, the performance is not that good. Instead of this, we introduce a write-ahead log to make our fsync faster. So if you do fsync for your data, it means your data is safely in the log tree, then if a crash takes place, the data can be recovered from log. More details are in tree-log.c. thanks, liubo -- 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
understanding the tree-log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Given how a transaction is committed, why is there a tree-log? When modifying the tree, either the super block is still pointing to the old tree root, or the new generation has been fully committed, so how can there ever be an intermediate state that needs a log to recover? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6zWiwACgkQJ4UciIs+XuK+FQCfTnTIu8iYgW38Qk3YoZ4KjA/9 uhwAnjOH36EkQ1EhoUdWg7OJr+0L0lbA =7DUz -END PGP SIGNATURE- -- 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 resize btrfs filesystem
Hello, I'm currently running Linux 3.0.7 (release "-1" under Arch 64bit) and btrfs-progs-unstable 0.19.20101006-1, I'm trying to resize my btrfs filesystem on /dev/sdb6, the partition has the room to allow expansion here's the output of "btrfs fi sh": failed to read /dev/sr0 Label: none uuid: db1a36b3-5047-4c14-8f67-262c2d63fcb8 Total devices 1 FS bytes used 388.51GB devid1 size 477.29GB used 416.29GB path /dev/sda6 Label: none uuid: d8685e5e-c9ba-4ba5-a147-0c2caf8f4b2d Total devices 1 FS bytes used 101.81GB devid1 size 552.08GB used 109.54GB path /dev/md127 Label: 'Storage2' uuid: 34115fbe-e9e3-4691-a3c6-715f5d30b4e5 Total devices 1 FS bytes used 196.73GB devid1 size 336.00GB used 336.00GB path /dev/sdb6 The command I'm running to resize the filesystem is "su -c "btrfs fi re 1:max /home/jordan/Storage/Storage2/"" and here's the output: Resize '/home/jordan/Storage/Storage2/' of '1:max' ERROR: unable to resize '/home/jordan/Storage/Storage2/ Thanks. -- 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: Warnings and crash
On Wed, Nov 2, 2011 at 6:40 PM, Chris Mason wrote: > On Thu, Nov 03, 2011 at 12:02:31AM +0100, David Sterba wrote: >> This one happened again, exactly same sequence of warnings and the crash >> at the end (same stack traces). It was in integration-scrub branch, ie. >> with all fixes on top. >> >> (I have captured sysrq-w, /proc/pid/stack of all processes and have the >> dmesg logs if anybody is interested.) > > Yes, I'd like to see the logs. We need to figure out if we just failed > with enospc in a critical spot or if there are other bigger problems. > I'm seeing similar warnings while testing the integration-scrub branch. I'm testing on a 16-GB partition that is less than 20% full when I'm seeing the warning. Let me know if you're still working on this issue, and I'll try to isolate the command that is running. [ 8631.183234] device fsid aff24946-5596-4c19-a6c4-81809ae6bd94 devid 1 transid 7 /dev/sdb6 [ 8631.183483] btrfs: disk space caching is enabled [ 8712.675332] btrfs: block rsv returned -28 [ 8712.675334] [ cut here ] [ 8712.675362] WARNING: at fs/btrfs/extent-tree.c:5837 btrfs_alloc_free_block+0x3e9/0x400 [btrfs]() [ 8712.675364] Hardware name: P35-DS3L [ 8712.675365] Modules linked in: ipv6 snd_seq_midi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss lgdt330x cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core rc_hauppauge tuner_simple tuner_types tda9887 tda8290 tuner nvidia(P) ir_lirc_codec lirc_dev ir_mce_kbd_decoder cx88_alsa cx8800 ir_sony_decoder ir_jvc_decoder ir_rc6_decoder cx8802 cx88xx snd_ens1371 ir_rc5_decoder ir_nec_decoder gameport snd_rawmidi snd_seq_device rc_core i2c_algo_bit snd_ac97_codec videobuf_dma_sg tveeprom v4l2_common videodev media v4l2_compat_ioctl32 videobuf_core btcx_risc iTCO_wdt iTCO_vendor_support intel_agp intel_gtt ac97_bus snd_pcm snd_timer i2c_i801 snd i2c_core snd_page_alloc ppdev parport_pc parport tpm_tis tpm r8169 tpm_bios sr_mod pcspkr iscsi_tcp libiscsi_tcp libiscsi fuse nfs nfs_acl auth_rpcgss lockd sunrpc btrfs zlib_deflate sl811_hcd ohci_hcd uhci_hcd ehci_hcd [ 8712.675409] Pid: 7917, comm: btrfs-transacti Tainted: P 3.1.0-integration-scrub+ #1 [ 8712.675411] Call Trace: [ 8712.675417] [] warn_slowpath_common+0x7f/0xc0 [ 8712.675420] [] warn_slowpath_null+0x1a/0x20 [ 8712.675428] [] btrfs_alloc_free_block+0x3e9/0x400 [btrfs] [ 8712.675435] [] ? btrfs_leaf_free_space+0x61/0xb0 [btrfs] [ 8712.675442] [] __btrfs_cow_block+0x119/0x560 [btrfs] [ 8712.675451] [] ? btrfs_buffer_uptodate+0x50/0x70 [btrfs] [ 8712.675458] [] btrfs_cow_block+0x1b9/0x2f0 [btrfs] [ 8712.675465] [] btrfs_search_slot+0x5c0/0xa90 [btrfs] [ 8712.675473] [] btrfs_write_dirty_block_groups+0xd9/0x530 [btrfs] [ 8712.675481] [] ? btrfs_run_delayed_refs+0xf2/0x210 [btrfs] [ 8712.675490] [] commit_cowonly_roots+0x115/0x1e0 [btrfs] [ 8712.675499] [] btrfs_commit_transaction+0x404/0x8a0 [btrfs] [ 8712.675508] [] ? join_transaction.clone.24+0x21/0x240 [btrfs] [ 8712.675511] [] ? wake_up_bit+0x40/0x40 [ 8712.675520] [] transaction_kthread+0x263/0x280 [btrfs] [ 8712.675528] [] ? btrfs_congested_fn+0xb0/0xb0 [btrfs] [ 8712.675536] [] ? btrfs_congested_fn+0xb0/0xb0 [btrfs] [ 8712.675539] [] kthread+0x96/0xa0 [ 8712.675542] [] kernel_thread_helper+0x4/0x10 [ 8712.675545] [] ? kthread_worker_fn+0x1a0/0x1a0 [ 8712.675547] [] ? gs_change+0xb/0xb [ 8712.675549] ---[ end trace 234618ad5fea81a4 ]--- -- 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: WARNING: at fs/btrfs/free-space-cache.c:305
(2011/11/03 20:19), Chris Mason wrote: > On Thu, Nov 03, 2011 at 10:25:23AM +0900, Tsutomu Itoh wrote: >> In integration-scrub branch, following warning messages were displayed by >> running xfstests. >> >> # btrfs fi sh /dev/sdd4 >> Label: none uuid: 8f28d85c-e37c-4c1b-adef-2627ca59be78 >> Total devices 2 FS bytes used 31.49MB >> devid1 size 9.31GB used 9.31GB path /dev/sdd4 >> devid2 size 15.01GB used 9.29GB path /dev/sdc1 >> >> Btrfs Btrfs v0.19 >> # mount >> ... >> /dev/sdd4 on /test7 type btrfs (rw,compress=lzo) >> # >> >> Thanks, >> Tsutomu >> >> >> >> Nov 3 09:55:18 luna kernel: [ 939.732044] device fsid >> 8f28d85c-e37c-4c1b-adef-2627ca59be78 devid 1 transid 20510 /dev/sdd4 >> Nov 3 09:55:18 luna kernel: [ 939.732533] btrfs: use lzo compression >> Nov 3 09:55:18 luna kernel: [ 939.732536] btrfs: disk space caching is >> enabled >> Nov 3 09:55:18 luna kernel: [ 939.898190] [ cut here >> ] >> Nov 3 09:55:18 luna kernel: [ 939.898223] WARNING: at >> fs/btrfs/free-space-cache.c:305 io_ctl_map_page+0x29/0x76 [btrfs]() >> Nov 3 09:55:18 luna kernel: [ 939.898227] Hardware name: PRIMERGY >> Nov 3 09:55:18 luna kernel: [ 939.898229] Modules linked in: btrfs >> zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc >> 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles >> fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput >> ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt >> iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache >> jbd2 crc16 sd_mod crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi >> ata_generic ata_piix libata scsi_mod [last unloaded: microcode] >> Nov 3 09:55:18 luna kernel: [ 939.898291] Pid: 13337, comm: dd Not tainted >> 3.1.0integ-sc+ #1 >> Nov 3 09:55:18 luna kernel: [ 939.898294] Call Trace: >> Nov 3 09:55:18 luna kernel: [ 939.898303] [] >> warn_slowpath_common+0x85/0x9d >> Nov 3 09:55:18 luna kernel: [ 939.898308] [] >> warn_slowpath_null+0x1a/0x1c >> Nov 3 09:55:18 luna kernel: [ 939.898328] [] >> io_ctl_map_page+0x29/0x76 [btrfs] >> Nov 3 09:55:18 luna kernel: [ 939.898349] [] >> io_ctl_check_crc+0x62/0xdd [btrfs] > > Looks like io_ctl_read_bitmap will call io_ctl_check_crc with a mapped > page mapped. Any chance you're able to reproduce this? Yes. However, because the panic that David reported occurs, I cannot reproduce this problem though I executed xfstests again. Thanks, Tsutomu -- 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: WARNING: at fs/btrfs/free-space-cache.c:305
On Thu, Nov 03, 2011 at 10:25:23AM +0900, Tsutomu Itoh wrote: > In integration-scrub branch, following warning messages were displayed by > running xfstests. > > # btrfs fi sh /dev/sdd4 > Label: none uuid: 8f28d85c-e37c-4c1b-adef-2627ca59be78 > Total devices 2 FS bytes used 31.49MB > devid1 size 9.31GB used 9.31GB path /dev/sdd4 > devid2 size 15.01GB used 9.29GB path /dev/sdc1 > > Btrfs Btrfs v0.19 > # mount > ... > /dev/sdd4 on /test7 type btrfs (rw,compress=lzo) > # > > Thanks, > Tsutomu > > > > Nov 3 09:55:18 luna kernel: [ 939.732044] device fsid > 8f28d85c-e37c-4c1b-adef-2627ca59be78 devid 1 transid 20510 /dev/sdd4 > Nov 3 09:55:18 luna kernel: [ 939.732533] btrfs: use lzo compression > Nov 3 09:55:18 luna kernel: [ 939.732536] btrfs: disk space caching is > enabled > Nov 3 09:55:18 luna kernel: [ 939.898190] [ cut here > ] > Nov 3 09:55:18 luna kernel: [ 939.898223] WARNING: at > fs/btrfs/free-space-cache.c:305 io_ctl_map_page+0x29/0x76 [btrfs]() > Nov 3 09:55:18 luna kernel: [ 939.898227] Hardware name: PRIMERGY > Nov 3 09:55:18 luna kernel: [ 939.898229] Modules linked in: btrfs > zlib_deflate crc32c libcrc32c nfsd lockd nfs_acl auth_rpcgss autofs4 sunrpc > 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf cachefiles > fscache ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev > parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support > tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod > crc_t10dif megaraid_sas sr_mod cdrom floppy pata_acpi ata_generic ata_piix > libata scsi_mod [last unloaded: microcode] > Nov 3 09:55:18 luna kernel: [ 939.898291] Pid: 13337, comm: dd Not tainted > 3.1.0integ-sc+ #1 > Nov 3 09:55:18 luna kernel: [ 939.898294] Call Trace: > Nov 3 09:55:18 luna kernel: [ 939.898303] [] > warn_slowpath_common+0x85/0x9d > Nov 3 09:55:18 luna kernel: [ 939.898308] [] > warn_slowpath_null+0x1a/0x1c > Nov 3 09:55:18 luna kernel: [ 939.898328] [] > io_ctl_map_page+0x29/0x76 [btrfs] > Nov 3 09:55:18 luna kernel: [ 939.898349] [] > io_ctl_check_crc+0x62/0xdd [btrfs] Looks like io_ctl_read_bitmap will call io_ctl_check_crc with a mapped page mapped. Any chance you're able to reproduce this? -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: [PATCH v8 1/8] btrfs: added helper functions to iterate backrefs
On 03.11.2011 02:41, Li Zefan wrote: > (as this is going to be merged into mainline..) > >> +/* >> + * calls iterate() for every inode that references the extent identified by >> + * the given parameters. will use the path given as a parameter and return >> it >> + * released. >> + * when the iterator function returns a non-zero value, iteration stops. >> + */ >> +int iterate_extent_inodes(struct btrfs_fs_info *fs_info, >> +struct btrfs_path *path, >> +u64 extent_item_objectid, >> +u64 extent_offset, >> +iterate_extent_inodes_t *iterate, void *ctx) > > While trying to use this API, I found there's a big defect in this function. > >fs_tree 1 fs_tree 2 >\ / > \/ > \ / > \/ > node > | > | > leaf (EXTENT_DATA item) > > In the above case, the function will find only 1 reference. Hum. You are right. I'm convinced that I've been at this point months ago, only I cannot find code dealing with counts > 1 on nodes. I'll look for a fix in my branches or make a new one. I also recognized that some "btrfs_" prefixes are missing for the exported functions. I'm going to change this on the next iteration as well. Currently, this is more of a best-effort resolver. Support for delayed extents is missing, it should be used on commit roots to get a consistent state. For the userspace part, at least the simple scenario outlined isn't crucial as "btrfs inspect-internal logical-resolve" will find each of the two paths, depending on the subvolume path you specify. It never finds both, though, which I agree it should. Sigh, -Jan -- 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 1/3] xfstests 264: add a copy and reserve test
On 11/03/2011 02:55 PM, Christoph Hellwig wrote: > On Thu, Nov 03, 2011 at 11:08:55AM +0800, WuBo wrote: >> This test is a stress test. It creates a set of threads for coping small >> files >> into disk. I use a 2G disk for test, the ENOSPC arises usually but the disk >> is >> not full under kenerl 3.0 with intel64. > > It seems like you really want to use _scratch_mkfs_sized instead of the > btrfs-specific resize option and make the test generic. Also we already OK, thanks for _scratch_mkfs_sized, It's will make these tests generic. > have used up these test numbers in the xfstests-dev repository, and I > will commit another batch of tests today. I will change my test numbers in next version. thanks, wubo > > -- > 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
