Re: Regression in 2.6.35 RC1 (Ubuntu 2.6.35-1-generic)
On Fri, Jun 11, 2010 at 12:54 PM, Brad Figg brad.f...@canonical.com wrote: I'm seeing the following in /var/log/messages. The system is not under any particular load. The system has my /home as a btrfs partition. The system has GDM up and I've logged in via ssh. Jun 10 21:22:43 bradf-x301 kernel: [ 175.563934] CPU 1 Jun 10 21:22:43 bradf-x301 kernel: [ 175.563937] Modules linked in: cryptd aes_x86_64 aes_generic rfcomm binfmt_misc sco ppdev bridge stp bnep l2cap dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq snd_timer snd_seq_device uvcvideo lp iwlagn videodev parport iwlcore btusb mac80211 v4l1_compat snd cfg80211 bluetooth joydev soundcore v4l2_compat_ioctl32 psmouse tpm_tis tpm serio_raw tpm_bios led_class nvram snd_page_alloc btrfs zlib_deflate crc32c libcrc32c vga16fb vgastate usbhid hid i915 drm_kms_helper drm ahci i2c_algo_bit video e1000e output libahci intel_agp Jun 10 21:22:43 bradf-x301 kernel: [ 175.564051] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564059] Pid: 936, comm: btrfs-endio-wri Tainted: G W 2.6.35-1-generic #1-Ubuntu 2777MSU/2777MSU Jun 10 21:22:43 bradf-x301 kernel: [ 175.564066] RIP: 0010:[a015916b] [a015916b] btrfs_free_tree_block+0x3bb/0x3e0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564102] RSP: 0018:8801282638f0 EFLAGS: 00010287 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564108] RAX: 8801326c5b00 RBX: 88013279e800 RCX: 8801326c5300 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564114] RDX: 000181ff RSI: 00014000 RDI: 8801304dc070 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564121] RBP: 880128263940 R08: R09: 0007 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564126] R10: 0001 R11: R12: 880123dba7e0 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564132] R13: 8801304dc128 R14: 880123dbd000 R15: 8801326c5300 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564139] FS: () GS:880001e8() knlGS: Jun 10 21:22:43 bradf-x301 kernel: [ 175.564146] CS: 0010 DS: ES: CR0: 8005003b Jun 10 21:22:43 bradf-x301 kernel: [ 175.564152] CR2: 7f1a263e4e40 CR3: 01a2a000 CR4: 06e0 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564158] DR0: DR1: DR2: Jun 10 21:22:43 bradf-x301 kernel: [ 175.564164] DR3: DR6: 0ff0 DR7: 0400 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564171] Process btrfs-endio-wri (pid: 936, threadinfo 880128262000, task 880128635b40) Jun 10 21:22:43 bradf-x301 kernel: [ 175.564179] 88010002 880130b301b8 b242 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564189] 0 880128263940 88013081c630 880123dba900 88013279e800 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564199] 0 880123dba7e0 880123dbd000 8801282639f0 a014992b Jun 10 21:22:43 bradf-x301 kernel: [ 175.564234] [a014992b] __btrfs_cow_block+0x3bb/0x620 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564257] [a0149c97] btrfs_cow_block+0x107/0x1f0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564280] [a015086e] btrfs_search_slot+0x37e/0x6b0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564308] [a016104d] btrfs_lookup_csum+0x6d/0x160 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564321] [81140915] ? kmem_cache_alloc+0xe5/0x140 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564347] [a0161d29] btrfs_csum_file_blocks+0xd9/0x850 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564380] [a0186b9e] ? merge_state+0x7e/0x150 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564411] [a0186317] ? free_extent_state+0x37/0x60 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564442] [a016b4b9] add_pending_csums+0x49/0x70 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564471] [a016d7f3] btrfs_finish_ordered_io+0x1a3/0x2a0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564482] [81108aed] ? test_clear_page_writeback+0x8d/0x150 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564512] [a016d90a] btrfs_writepage_end_io_hook+0x1a/0x20 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564542] [a018822b] end_bio_extent_writepage+0x13b/0x180 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564553] [8158235d] ? schedule_timeout+0x19d/0x310 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564564] [8106e1d0] ? process_timeout+0x0/0x10 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564573] [8117da1d] bio_endio+0x1d/0x40 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564601] [a01641ec] end_workqueue_fn+0xfc/0x130 [btrfs] Jun 10 21:22:43 bradf-x301
Re: bcp command not installed by Makefile
On Friday 11 of June 2010 03:46:11 Palmer Cox wrote: Is there a reason the bcp command isn't installed when running make install? If not, here is a really simple patch to add it to the install. -Palmer Cox Does 'bcp' can do anything additional that the 'cp --reflink=always'? -- 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 System Zarządzania Jakością zgodny z normą ISO 9001:2000 -- 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: Regression in 2.6.35 RC1 (Ubuntu 2.6.35-1-generic)
On 06/10/2010 11:33 PM, Yan, Zheng wrote: On Fri, Jun 11, 2010 at 12:54 PM, Brad Figgbrad.f...@canonical.com wrote: I'm seeing the following in /var/log/messages. The system is not under any particular load. The system has my /home as a btrfs partition. The system has GDM up and I've logged in via ssh. Jun 10 21:22:43 bradf-x301 kernel: [ 175.563934] CPU 1 Jun 10 21:22:43 bradf-x301 kernel: [ 175.563937] Modules linked in: cryptd aes_x86_64 aes_generic rfcomm binfmt_misc sco ppdev bridge stp bnep l2cap dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm thinkpad_acpi snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq snd_timer snd_seq_device uvcvideo lp iwlagn videodev parport iwlcore btusb mac80211 v4l1_compat snd cfg80211 bluetooth joydev soundcore v4l2_compat_ioctl32 psmouse tpm_tis tpm serio_raw tpm_bios led_class nvram snd_page_alloc btrfs zlib_deflate crc32c libcrc32c vga16fb vgastate usbhid hid i915 drm_kms_helper drm ahci i2c_algo_bit video e1000e output libahci intel_agp Jun 10 21:22:43 bradf-x301 kernel: [ 175.564051] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564059] Pid: 936, comm: btrfs-endio-wri Tainted: GW 2.6.35-1-generic #1-Ubuntu 2777MSU/2777MSU Jun 10 21:22:43 bradf-x301 kernel: [ 175.564066] RIP: 0010:[a015916b] [a015916b] btrfs_free_tree_block+0x3bb/0x3e0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564102] RSP: 0018:8801282638f0 EFLAGS: 00010287 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564108] RAX: 8801326c5b00 RBX: 88013279e800 RCX: 8801326c5300 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564114] RDX: 000181ff RSI: 00014000 RDI: 8801304dc070 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564121] RBP: 880128263940 R08: R09: 0007 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564126] R10: 0001 R11: R12: 880123dba7e0 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564132] R13: 8801304dc128 R14: 880123dbd000 R15: 8801326c5300 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564139] FS: () GS:880001e8() knlGS: Jun 10 21:22:43 bradf-x301 kernel: [ 175.564146] CS: 0010 DS: ES: CR0: 8005003b Jun 10 21:22:43 bradf-x301 kernel: [ 175.564152] CR2: 7f1a263e4e40 CR3: 01a2a000 CR4: 06e0 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564158] DR0: DR1: DR2: Jun 10 21:22:43 bradf-x301 kernel: [ 175.564164] DR3: DR6: 0ff0 DR7: 0400 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564171] Process btrfs-endio-wri (pid: 936, threadinfo 880128262000, task 880128635b40) Jun 10 21:22:43 bradf-x301 kernel: [ 175.564179] 88010002 880130b301b8 b242 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564189]0 880128263940 88013081c630 880123dba900 88013279e800 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564199]0 880123dba7e0 880123dbd000 8801282639f0 a014992b Jun 10 21:22:43 bradf-x301 kernel: [ 175.564234] [a014992b] __btrfs_cow_block+0x3bb/0x620 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564257] [a0149c97] btrfs_cow_block+0x107/0x1f0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564280] [a015086e] btrfs_search_slot+0x37e/0x6b0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564308] [a016104d] btrfs_lookup_csum+0x6d/0x160 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564321] [81140915] ? kmem_cache_alloc+0xe5/0x140 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564347] [a0161d29] btrfs_csum_file_blocks+0xd9/0x850 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564380] [a0186b9e] ? merge_state+0x7e/0x150 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564411] [a0186317] ? free_extent_state+0x37/0x60 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564442] [a016b4b9] add_pending_csums+0x49/0x70 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564471] [a016d7f3] btrfs_finish_ordered_io+0x1a3/0x2a0 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564482] [81108aed] ? test_clear_page_writeback+0x8d/0x150 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564512] [a016d90a] btrfs_writepage_end_io_hook+0x1a/0x20 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564542] [a018822b] end_bio_extent_writepage+0x13b/0x180 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564553] [8158235d] ? schedule_timeout+0x19d/0x310 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564564] [8106e1d0] ? process_timeout+0x0/0x10 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564573] [8117da1d] bio_endio+0x1d/0x40 Jun 10 21:22:43 bradf-x301 kernel: [ 175.564601] [a01641ec] end_workqueue_fn+0xfc/0x130 [btrfs] Jun 10 21:22:43 bradf-x301 kernel: [ 175.564629] [a01942cc]
Re: [PATCH] fs: make sure to invalidate pages if we fall back on buffered reads
Josef Bacik jo...@redhat.com writes:
Since BTRFS can fallback on buffered reads after having done some direct
reads,
we need to make sure to invalidate any pages that we may have read by doing
buffered IO. This shouldn't have shown up as a visible user problem, it's
just
for correctness sake. Thanks,
This looks right to me. You definitely don't want to fill up the page
cache from direct I/O.
Reviewed-by: Jeff Moyer jmo...@redhat.com
Signed-off-by: Josef Bacik jo...@redhat.com
---
mm/filemap.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 829ac9c..ca5aba9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1266,6 +1266,7 @@ generic_file_aio_read(struct kiocb *iocb, const struct
iovec *iov,
unsigned long seg = 0;
size_t count;
loff_t *ppos = iocb-ki_pos;
+ bool invalidate = false;
count = 0;
retval = generic_segment_checks(iov, nr_segs, count, VERIFY_WRITE);
@@ -1291,7 +1292,8 @@ generic_file_aio_read(struct kiocb *iocb, const struct
iovec *iov,
iov, pos, nr_segs);
}
if (retval 0) {
- *ppos = pos + retval;
+ pos += retval;
+ *ppos = pos;
count -= retval;
}
@@ -1307,6 +1309,7 @@ generic_file_aio_read(struct kiocb *iocb, const struct
iovec *iov,
file_accessed(filp);
goto out;
}
+ invalidate = true;
}
}
@@ -1343,6 +1346,10 @@ generic_file_aio_read(struct kiocb *iocb, const struct
iovec *iov,
if (desc.count 0)
break;
}
+ if (invalidate retval 0)
+ invalidate_mapping_pages(filp-f_mapping,
+ pos PAGE_CACHE_SHIFT,
+ (*ppos - 1) PAGE_CACHE_SHIFT);
out:
return retval;
}
--
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
[GIT PULL] Btrfs updates for 2.6.35
Hello everyone, The master branch of the btrfs-unstable tree is a collection of fixes and cleanups, including two btrfs regressions from rc1: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git master One is an freeing blocks on an FS converted from ext34 to btrfs, and the other is a fallocate fix. The rest are the usual small bug fixes. Dan Carpenter (11) commits (+24/-17): Btrfs: handle error returns from btrfs_lookup_dir_item() (+2/-0) Btrfs: btrfs_read_fs_root_no_name() returns ERR_PTRs (+4/-0) Btrfs: unwind after btrfs_start_transaction() errors (+1/-1) Btrfs: remove unneeded null check in btrfs_rename() (+1/-3) Btrfs: The file argument for fsync() is never null (+1/-1) Btrfs: handle ERR_PTR from posix_acl_from_xattr() (+2/-0) Btrfs: btrfs_lookup_dir_item() can return ERR_PTR (+1/-1) Btrfs: uninitialized data is check_path_shared() (+1/-1) Btrfs: handle kzalloc() failure in open_ctree() (+5/-2) Btrfs: silence sparse warnings in ioctl.c (+4/-6) Btrfs: btrfs_iget() returns ERR_PTR (+2/-2) Zheng Yan (2) commits (+6/-4): Btrfs: Fix BUG_ON for fs converted from extN (+2/-1) Btrfs: Fix null dereference in relocation.c (+4/-3) Liu Bo (2) commits (+14/-4): Btrfs: Add error check for add_to_page_cache_lru (+13/-3) Btrfs: fix break in btrfs_insert_some_items() (+1/-1) Julia Lawall (2) commits (+9/-17): Btrfs: Use memdup_user (+6/-14) Btrfs: Use ERR_CAST (+3/-3) Shi Weihua (2) commits (+6/-0): Btrfs: prohibit a operation of changing acl's mask when noacl mount option used (+3/-0) Btrfs: should add a permission check for setfacl (+3/-0) Miao Xie (2) commits (+9/-1): Btrfs: fix loop device on top of btrfs (+1/-0) Btrfs: fix remap_file_pages error (+8/-1) Sage Weil (1) commits (+0/-3): Btrfs: avoid BUG when dropping root and reference in same transaction Andi Kleen (1) commits (+2/-94): BTRFS: Clean up unused variables -- nonbugs Josef Bacik (1) commits (+1/-1): Btrfs: fix fallocate regression Prarit Bhargava (1) commits (+1/-1): Btrfs: Fix warning in tree_search() Total: (25) commits (+72/-142) fs/btrfs/acl.c |8 fs/btrfs/compression.c | 18 +- fs/btrfs/ctree.c| 20 +--- fs/btrfs/disk-io.c | 22 +- fs/btrfs/extent-tree.c |5 ++--- fs/btrfs/extent_io.c|9 - fs/btrfs/extent_map.c |4 ++-- fs/btrfs/file.c | 12 ++-- fs/btrfs/inode.c| 22 +++--- fs/btrfs/ioctl.c| 36 fs/btrfs/ordered-data.c |4 +--- fs/btrfs/relocation.c |7 --- fs/btrfs/root-tree.c|5 - fs/btrfs/super.c| 14 +++--- fs/btrfs/tree-defrag.c |2 -- fs/btrfs/tree-log.c | 15 --- fs/btrfs/volumes.c |4 fs/btrfs/xattr.c|2 -- fs/btrfs/zlib.c |5 - 19 files changed, 72 insertions(+), 142 deletions(-) -- 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: Regression in 2.6.35 RC1 (Ubuntu 2.6.35-1-generic)
On Fri, Jun 11, 2010 at 09:00:10AM -0700, Brad Figg wrote: On 06/10/2010 11:33 PM, Yan, Zheng wrote: I have already sent a patch for this. http://www.spinics.net/lists/linux-btrfs/msg05150.html Yan, Zheng -- 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 I've not seen this patch hit lkml yet. This is now in the master branch of the btrfs-unstable tree. -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: [GIT PULL] Btrfs updates for 2.6.35
On Fri, Jun 11, 2010 at 12:37 PM, Chris Mason chris.ma...@oracle.com wrote: The master branch of the btrfs-unstable tree is a collection of fixes and cleanups, including two btrfs regressions from rc1: Ok, no pulling then. See all the millions of threads how I wanted only critical fixes for -rc3 since I'll be offline. You have a couple of hours for a minimal fix pull request with just the regression fixes if you want to hit -rc3. Then I'll cut a release and be gone for a while. Linus -- 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: [GIT PULL] Btrfs updates for 2.6.35
On Fri, Jun 11, 2010 at 12:43:10PM -0700, Linus Torvalds wrote: On Fri, Jun 11, 2010 at 12:37 PM, Chris Mason chris.ma...@oracle.com wrote: The master branch of the btrfs-unstable tree is a collection of fixes and cleanups, including two btrfs regressions from rc1: Ok, no pulling then. See all the millions of threads how I wanted only critical fixes for -rc3 since I'll be offline. You have a couple of hours for a minimal fix pull request with just the regression fixes if you want to hit -rc3. Then I'll cut a release and be gone for a while. I did limit this to actual fixes, the only pure cleanups are a commit from Andi that drops unused code (fixing warnings from gcc), one to fix a sparse warning in ioctl.c, and fixing a gcc warning in tree_search. The others all fix oopsen or big problems, and I think fixing warnings helps avoid false negatives as others look for real problems? I'm happy to rebase out the 3 non-criticals. -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: [GIT PULL] Btrfs updates for 2.6.35
On Fri, Jun 11, 2010 at 12:48 PM, Chris Mason chris.ma...@oracle.com wrote: The others all fix oopsen or big problems, and I think fixing warnings helps avoid false negatives as others look for real problems? I'm happy to rebase out the 3 non-criticals. There seems to be more than three non-criticals. There's the warning fixes, the unused variables thing, the memdup_user() thing, a couple of unnecessary NULL checks removed etc. On the whole, I do not get the feeling that the pull request was actively trying to be minimal, and that's what I really want to see. Linus -- 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: [GIT PULL] Btrfs updates for 2.6.35
On Fri, Jun 11, 2010 at 01:00:02PM -0700, Linus Torvalds wrote: On Fri, Jun 11, 2010 at 12:48 PM, Chris Mason chris.ma...@oracle.com wrote: The others all fix oopsen or big problems, and I think fixing warnings helps avoid false negatives as others look for real problems? I'm happy to rebase out the 3 non-criticals. There seems to be more than three non-criticals. There's the warning fixes, the unused variables thing, the memdup_user() thing, a couple of unnecessary NULL checks removed etc. On the whole, I do not get the feeling that the pull request was actively trying to be minimal, and that's what I really want to see. No problem, I like to err on the side of pulling in safe fixes from the automated checkers so they don't have to go through results again. But, I've got a completely minimal rebase now and I'm double checking it. -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: [GIT PULL] Btrfs updates for 2.6.35
On Fri, Jun 11, 2010 at 01:00:02PM -0700, Linus Torvalds wrote: On Fri, Jun 11, 2010 at 12:48 PM, Chris Mason chris.ma...@oracle.com wrote: The others all fix oopsen or big problems, and I think fixing warnings helps avoid false negatives as others look for real problems? I'm happy to rebase out the 3 non-criticals. There seems to be more than three non-criticals. There's the warning fixes, the unused variables thing, the memdup_user() thing, a couple of unnecessary NULL checks removed etc. On the whole, I do not get the feeling that the pull request was actively trying to be minimal, and that's what I really want to see. The for-linus branch (note the change in branch name) has everything that doesn't fix a bug removed. git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus I'll update the master branch to reflect any pulls you do. Dan Carpenter (9) commits (+19/-8): Btrfs: handle error returns from btrfs_lookup_dir_item() (+2/-0) Btrfs: btrfs_read_fs_root_no_name() returns ERR_PTRs (+4/-0) Btrfs: unwind after btrfs_start_transaction() errors (+1/-1) Btrfs: The file argument for fsync() is never null (+1/-1) Btrfs: handle ERR_PTR from posix_acl_from_xattr() (+2/-0) Btrfs: btrfs_lookup_dir_item() can return ERR_PTR (+1/-1) Btrfs: uninitialized data is check_path_shared() (+1/-1) Btrfs: handle kzalloc() failure in open_ctree() (+5/-2) Btrfs: btrfs_iget() returns ERR_PTR (+2/-2) Zheng Yan (2) commits (+6/-4): Btrfs: Fix BUG_ON for fs converted from extN (+2/-1) Btrfs: Fix null dereference in relocation.c (+4/-3) Shi Weihua (2) commits (+6/-0): Btrfs: prohibit a operation of changing acl's mask when noacl mount option used (+3/-0) Btrfs: should add a permission check for setfacl (+3/-0) Miao Xie (2) commits (+9/-1): Btrfs: fix loop device on top of btrfs (+1/-0) Btrfs: fix remap_file_pages error (+8/-1) Sage Weil (1) commits (+0/-3): Btrfs: avoid BUG when dropping root and reference in same transaction Josef Bacik (1) commits (+1/-1): Btrfs: fix fallocate regression Total: (17) commits (+41/-17) fs/btrfs/acl.c |8 fs/btrfs/disk-io.c | 11 +-- fs/btrfs/extent-tree.c |3 ++- fs/btrfs/file.c| 12 ++-- fs/btrfs/inode.c |4 ++-- fs/btrfs/ioctl.c |4 ++-- fs/btrfs/relocation.c |7 --- fs/btrfs/root-tree.c |3 --- fs/btrfs/super.c |6 -- 9 files changed, 41 insertions(+), 17 deletions(-) -- 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: bcp command not installed by Makefile
I guess not. I thought that bcp was letting me do a reflink copy of a file from one subvolume to the another while cp was not. Anyway, I looked through the code and realized that bcp was just falling back to a regular copy. oh well. -Palmer Cox On Fri, Jun 11, 2010 at 8:12 AM, Hubert Kario h...@qbs.com.pl wrote: On Friday 11 of June 2010 03:46:11 Palmer Cox wrote: Is there a reason the bcp command isn't installed when running make install? If not, here is a really simple patch to add it to the install. -Palmer Cox Does 'bcp' can do anything additional that the 'cp --reflink=always'? -- 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 System Zarządzania Jakością zgodny z normą ISO 9001:2000 -- 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
Question: Build btrfs filesystem from specific directory.
Dear all, I'm not sure it's correct mailing list. but I can't find a btrfs-progs mailing list. I'm founding the solution to build btrfs filesystem image from specific directory. it's common concept at mobile build environment. e.g., ubifs and cramfs support this feature. In case of ubifs -r, -d, --root=DIR build file system from directory DIR In case of cramfs dirnameroot of the filesystem to be compressed But btrfs doesn't support it. usage: mkfs.btrfs [options] dev [ dev ... ] options: -A --alloc-start the offset to start the FS -b --byte-count total number of bytes in the FS -d --data data profile, raid0, raid1, raid10 or single -l --leafsize size of btree leaves -L --label set a label -m --metadata metadata profile, values like data profile -n --nodesize size of btree nodes -s --sectorsize min block allocation Btrfs v0.19-16-g075587c-dirty So does it have any plan to support this feature at btrfs? Thank you, Kyungmin Park -- 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: Question: Build btrfs filesystem from specific directory.
Hi, On Sat, Jun 12, 2010 at 11:33 AM, Evgeny A. Marchenko xeng...@mail.ru wrote: I'm founding the solution to build btrfs filesystem image from specific directory. it's common concept at mobile build environment. e.g., ubifs and cramfs support this feature. In case of ubifs -r, -d, --root=DIR build file system from directory DIR In case of cramfs dirname root of the filesystem to be compressed But btrfs doesn't support it. Maybe because btrfs is not a compressed read-only filesystem It's just example. it's not matter to support compressed or not. So does it have any plan to support this feature at btrfs? You can create file-backed loop device, mount it and copy the directory contents there. Than unmount the loop and voila - you have btrfs image Right, I used it now, but some build machine doesn't have or support btrfs, it mean can't mount btrfs as loopback. I just want to create btrfs image from directory without any host machine dependency such as kernel version and whatever. To simply, just use the mkfs.btrfs itself. Thank you, Kyungmin Park -- 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: default subvolume abilities/restrictions
On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger anth...@extof.me wrote: .. i need a way, programmatically and safely, to move the users installation from the original subvolume into an isolated subvolume .. or to generate a new, empty default/root subvolume and place the current default subvol (.) _into_ it... how can this be done? can any devs out there make this happen? note, what i'm looking for is _not_ setting the default subvolume to be mounted, but actually moving/renaming the default (.) subvolume itself. essentially, can we get a command to do this: # btrfs subvolume create new_root # mv . new_root/old_root that unsurprisingly fails with: mv: cannot move `.' to `new_root/old_root': Device or resource busy could we extend btrfs-progs tools to allow something like this? does the on disk format support _moving_ the default subvol? this operation is critical to upgrade a user who has installed their system into the default subvol, as most naturally would. clean rollback systems/structures depend on the user having his system installed to an isolated subvol, NOT the default. what sayith you? thanks, C Anthony additionally, is anything like the following on a TODO list anywhere? thanks again. ps. a recursive snapshotting tool could be useful too (if / and /home were both subvols, the tool would create both when / was snapped, instead of /home being an empty folder in the snapshot [BUG?]). -- 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
