headers
Kyle Gates | 1 Feb 2012 01:22
Picon
Favicon

RE: btrfs-raid questions I couldn't find an answer to on the wiki

>> I've been having good luck with my /boot on a separate 1GB RAID1 btrfs
>> filesystem using grub2 (2 disks only! I wouldn't try it with 3). I
>> should note, however, that I'm NOT using compression on this volume
>> because if I remember correctly it may not play well with grub (maybe
>> that was just lzo though) and I'm also not using subvolumes either for
>> the same reason.
>
> Thanks! I'm on grub2 as well. It's is still masked on gentoo, but I
> recently unmasked and upgraded to it, taking advantage of the fact that I
> have two two-spindle md/raid-1s for /boot and its backup to test and
> upgrade one of them first, then the other only when I was satisfied with
> the results on the first set. I'll be using a similar strategy for the
> btrfs upgrades, only most of my md/raid-1s are 4-spindle, with two sets,
> working and backup, and I'll upgrade one set first.
>
> I'm going to keep /boot a pair of two-spindle raid-1s, but intend to make
> them btrfs-raid1s instead of md/raid-1s, and will upgrade one two-spindle
> set at a time.
>
> More on the status of grub2 btrfs-compression support based on my
> research. There is support for btrfs/gzip-compression in at least grub
> trunk. AFAIK, it's gzip-compression in grub-1.99-release and
> lzo-compression in trunk only, but I may be misremembering and it's gzip
> in trunk only and only uncompressed in grub-1.99-release.

I believe you are correct that btrfs zlib support is included in grub2 
version 1.99 and lzo is in trunk.
I'll try compressing the files on /boot for one installed kernel with the 
defrag -czlib option and see how it goes.
Result: Seemed to work just fine.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Krakow | 1 Feb 2012 02:05
Picon

[3.2.1] BUG at fs/btrfs/inode.c:1588

Just happened while writing a huge avi file to my usb3 backup disk:

[356036.596292] ------------[ cut here ]------------
[356036.596300] kernel BUG at fs/btrfs/inode.c:1588!
[356036.596304] invalid opcode: 0000 [#1] SMP 
[356036.596307] CPU 2 
[356036.596309] Modules linked in: vmnet(O) vmblock(O) vsock(O) vmci(O) 
vmmon(O) af_packet snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss 
snd_mixer_oss nls_iso8859_15 nls_cp437 vfat fat btusb bluetooth zram(C) loop 
snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_seq_device 
gspca_sonixj gspca_main videodev v4l2_compat_ioctl32 pcspkr i2c_i801 evdev 
unix fuse xfs nfs nfs_acl auth_rpcgss lockd sunrpc reiserfs scsi_wait_scan 
hid_monterey hid_microsoft hid_logitech hid_ezkey hid_cypress hid_chicony 
hid_cherry hid_belkin hid_apple hid_a4tech usbhid usb_storage hid sr_mod 
cdrom sg pata_cmd64x [last unloaded: microcode]
[356036.596346] 
[356036.596349] Pid: 28747, comm: btrfs-fixup-1 Tainted: G         C O 
3.2.1-gentoo-r2 #1 To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Pro3
[356036.596355] RIP: 0010:[<ffffffff811605fe>]  [<ffffffff811605fe>] 
btrfs_writepage_fixup_worker+0xde/0x121
[356036.596363] RSP: 0000:ffff8801e2379de0  EFLAGS: 00010246
[356036.596366] RAX: 0000000000000000 RBX: ffffea00019b1a00 RCX: 
0000000000000000
[356036.596370] RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 
ffff88008a1bbb40
[356036.596373] RBP: 00000000033fd000 R08: ffff8801e2379d2c R09: 
0000000180240024
[356036.596377] R10: 0000000000000000 R11: bf800000bf800000 R12: 
ffff88008a1bbc10
[356036.596380] R13: 0000000000000000 R14: ffff8801e2379df8 R15:
(Continue reading)

Permalink | Reply | 10 comments |
headers
Cong Wang | 1 Feb 2012 03:07
Picon

Re: How to get trace during crash?

On 02/01/2012 02:04 AM, Chester wrote:
> In the event of a filesystem crash, how do I extract the debugging
> info for the mailing list? My attempts to SSH into the machine are
> unresponsive.
>

In this case, probably you need netconsole, see 
Documentation/networking/netconsole.txt for details.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Thomas Weber | 1 Feb 2012 06:20

Re: btrfs bug

Hello Mitch,

I have good news for you. I looked through all log files and found in 
the everything.log the following:

Regards,
Thomas

Jan 31 05:12:24 localhost kernel: [87276.968049] btrfs memmove bogus 
src_offset 1870 move len 687876531 len 4096
Jan 31 05:12:24 localhost kernel: [87276.968136] ------------[ cut here 
]------------
Jan 31 05:12:24 localhost kernel: [87276.968222] kernel BUG at 
fs/btrfs/extent_io.c:4357!
Jan 31 05:12:24 localhost kernel: [87276.968296] invalid opcode: 0000 
[#1] PREEMPT SMP
Jan 31 05:12:24 localhost kernel: [87276.968388] CPU 1
Jan 31 05:12:24 localhost kernel: [87276.968423] Modules linked in: nfs 
nfs_acl lockd auth_rpcgss sunrpc des_generic ecb md4 md5 hmac nls_utf8 
cifs fscache aes_generic ipv6 ext2 mbcache joydev arc4 dell_wmi 
sparse_keymap i915 snd_hda_codec_idt iwl3945 iwl_legacy psmouse 
snd_hda_intel serio_raw evdev pcspkr snd_hda_codec drm_kms_helper 
snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer drm cfg80211 
i2c_algo_bit i2c_i801 tg3 snd iTCO_wdt iTCO_vendor_support soundcore 
rfkill i2c_core libphy wmi intel_agp intel_gtt thermal button battery 
video processor ac btrfs crc32c libcrc32c zlib_deflate sd_mod pata_acpi 
uhci_hcd ata_piix libata scsi_mod ehci_hcd usbcore usb_common
Jan 31 05:12:24 localhost kernel: [87276.969644]
Jan 31 05:12:24 localhost kernel: [87276.969674] Pid: 15299, comm: 
btrfs-endio-wri Not tainted 3.2.2-1-ARCH #1 Dell Inc. Latitude
(Continue reading)

Permalink | Reply | 1 comment |
headers
Duncan | 1 Feb 2012 07:59
Picon

Re: btrfs-raid questions I couldn't find an answer to on the wiki

Kyle Gates posted on Tue, 31 Jan 2012 18:22:51 -0600 as excerpted:

> I don't think I specifically enabled mixed chunk support when I created
> this filesystem. It was done on a 2.6 kernel sometime in the middle of
> 2011 iirc.

Yeah, I'd guess that was before mixed-chunk, or at least before it became 
the default for <=1GiB filesystems, so even if it was supported it 
wouldn't have been the default.

Meaning there's still an open question as to whether grub-1.99 supports 
mixed-chunk.

It looks like I might get more time to play with it this coming week than 
I had this past week.  I might try some of my own experiments... and 
whether grub groks mixed-chunk will certainly be among them if I do.

As for those recommending something other than btrfs for /boot, yes, 
that's a possibility, but I strongly prefer to standardize on a single 
filesystem type.  Right now, that's reiserfs for everything except flash-
based USB and legacy floppies (both of which I use ext4 without 
journaling for, except for the floppies I used to update my BIOS, before 
my 2003 era mainboard got EOLed; those were freedos images), and 
ultimately, I hope it'll be btrfs for everything including flash-based 
(tho perhaps not for legacy floppies, but it has been awhile since I used 
one of them for anything, after that last BIOS update...).

Of course I'm going to keep reiserfs on my backups, even if I use btrfs 
for my working system, for the time being since btrfs is still in heavy 
development, but ultimately, I want to go all btrfs just as I'm all
(Continue reading)

Permalink | Reply | 0 comments |
headers
Li Zefan | 1 Feb 2012 10:34
Favicon

Re: [PATCH] Btrfs: allow cloning ranges within the same file

>> It's safe and easy to do so, provided the ranges don't overlap.
>>
>> Signed-off-by: Li Zefan <lizf <at> cn.fujitsu.com>
>> ---
>>  fs/btrfs/ioctl.c |   23 ++++++++++++++++-------
>>  1 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
>> index 0b06a5c..8fcd671 100644
>> --- a/fs/btrfs/ioctl.c
>> +++ b/fs/btrfs/ioctl.c
>>  <at>  <at>  -2223,8 +2223,6  <at>  <at>  static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
>>  	 *   decompress into destination's address_space (the file offset
>>  	 *   may change, so source mapping won't do), then recompress (or
>>  	 *   otherwise reinsert) a subrange.
>> -	 * - allow ranges within the same file to be cloned (provided
>> -	 *   they don't overlap)?
>>  	 */
>>  
>>  	/* the destination must be opened for writing */
>>  <at>  <at>  -2247,8 +2245,6  <at>  <at>  static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
>>  	src = src_file->f_dentry->d_inode;
>>  
>>  	ret = -EINVAL;
>> -	if (src == inode)
>> -		goto out_fput;
>>  
>>  	/* the src must be open for reading */
>>  	if (!(src_file->f_mode & FMODE_READ))
>>  <at>  <at>  -2282,9 +2278,11  <at>  <at>  static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Li Zefan | 1 Feb 2012 10:44
Favicon

Re: [PATCH 12/12] Btrfs: Fix file clone when source offset is not 0

Jan Schmidt wrote:
> On 30.01.2012 07:33, Li Zefan wrote:
>> Jan Schmidt wrote:
>>> I was looking at the clone range ioctl and have some remarks:
>>>
>>> On 27.01.2011 09:46, Li Zefan wrote:
>>>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
>>>> index f87552a..1b61dab 100644
>>>> --- a/fs/btrfs/ioctl.c
>>>> +++ b/fs/btrfs/ioctl.c
>>>>  <at>  <at>  -1788,7 +1788,10  <at>  <at>  static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd,
>>>>  
>>>>  			memcpy(&new_key, &key, sizeof(new_key));
>>>>  			new_key.objectid = inode->i_ino;
>>>> -			new_key.offset = key.offset + destoff - off;
>>>> +			if (off <= key.offset)
>>>> +				new_key.offset = key.offset + destoff - off;
>>>> +			else
>>>> +				new_key.offset = destoff;
>>> 						 ^^^^^^^
>>> 1) This looks spurious to me. What if destoff isn't aligned? That's what
>>> the "key.offset - off" code above is for. Before the patch, the code
>>> didn't work at all, I agree. But this fix can only work for aligned
>>> requests.
>>>
>>> 2) The error in new_key also has propagated to the extent item's backref
>>> and wasn't fixed there. I did a range clone and ended up with an extent
>>> item like that:
>>>         item 30 key (1318842368 EXTENT_ITEM 131072) itemoff 1047
>>> itemsize 169
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Mason | 1 Feb 2012 18:56
Picon
Favicon

Re: brtfs on top of dmcrypt with SSD. No corruption iff write cache off?

On Sun, Jan 29, 2012 at 04:37:54PM -0800, Marc MERLIN wrote:
> Howdy,
> 
> I'm considering using brtfs for my new laptop install.
> 
> Encryption is however a requirement, and ecryptfs doesn't quite cut it for
> me, so that leaves me with dmcrypt which is what I've been using with
> ext3/ext4 for years.
> 
> https://btrfs.wiki.kernel.org/articles/g/o/t/Gotchas.html 
> still states that 
> 'dm-crypt block devices require write-caching to be turned off on the
> underlying HDD'
> While the report was for 2.6.33, I'll assume it's still true.
> 
> 
> I was considering migrating to a recent 256GB SSD and 3.2.x kernel.
> 
> First, I'd like to check if the 'turn off write cache' comment is still
> accurate and if it does apply to SSDs too.
> 
> Second, I was wondering if anyone is running btrfs over dmcrypt on an SSD
> and what the performance is like with write cache turned off (I'm actually
> not too sure what the impact is for SSDs considering that writing to flash
> can actually be slower than writing to a hard drive).

Performance without the cache on is going to vary wildly from one SSD to
another.  Some really need it to give them nice fat writes while others
do better on smaller writes.  It's best to just test yours and see.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Mitch Harder | 1 Feb 2012 19:07

Re: btrfs bug

On Tue, Jan 31, 2012 at 11:20 PM, Thomas Weber
<thomas.weber.linux <at> googlemail.com> wrote:
> Hello Mitch,
>
> I have good news for you. I looked through all log files and found in the
> everything.log the following:
>
> Regards,
> Thomas
>
>
> Jan 31 05:12:24 localhost kernel: [87276.968049] btrfs memmove bogus
> src_offset 1870 move len 687876531 len 4096
> Jan 31 05:12:24 localhost kernel: [87276.968136] ------------[ cut here
> ]------------
> Jan 31 05:12:24 localhost kernel: [87276.968222] kernel BUG at
> fs/btrfs/extent_io.c:4357!
> Jan 31 05:12:24 localhost kernel: [87276.968296] invalid opcode: 0000 [#1]
> PREEMPT SMP

[...snip...]

This is coming from a BUG_ON(1) in the memcpy_extent_buffer() function
in extent_io.c

	if (src_offset + len > dst->len) {
		printk(KERN_ERR "btrfs memmove bogus src_offset %lu move "
		       "len %lu dst len %lu\n", src_offset, len, dst->len);
		BUG_ON(1);
	}
(Continue reading)

Permalink | Reply | 0 comments |

Gmane