Am Montag, 26. März 2012 schrieb Calvin Walton:
> On Mon, 2012-03-26 at 10:51 +0200, Karel Zak wrote:
> > On Sat, Mar 24, 2012 at 06:21:05PM +, Hugo Mills wrote:
> > >As Sadner says, you have to run "btrfs dev scan" before you try
> > >to
> > >
> > > mount the FS. If you have root on b
Hi all
$ uname -a
Gentoo Linux s9 3.3.1-pf #2 SMP PREEMPT Mon Apr 9 00:35:28 EEST 2012
i686 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
I was running stuff for the past year or so on 4 partitions:
/dev/sda1 -> dm-crypt -> btrfs raid 0 ROOT 10.0GB
/dev/sda2 -> dm-crypt -> b
Leho Kraav kraav.com> writes:
[]
> Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond end
> of device
> Apr 8 02:46:11 s9 kernel: [ 189.691787] dm-3: rw=129, want=23361976,
> limit=20967424
I recently bumped into this too [1]. Liu Bo posted a patch for it [2],
which tests out fi
On 8 April 2012 16:49, Liu Bo wrote:
> On 04/06/2012 07:36 PM, Daniel J Blueman wrote:
>> Hi Josef, Chris,
>>
>> When testing BTRFS with RAID 0 metadata on linux-3.4-rc1, we see
>> discard ranges exceeding the end of the block device [1], potentially
>> causing dataloss; when this occurs, filesyst
On 09.04.2012 17:35, Daniel J Blueman wrote:
Leho Kraav kraav.com> writes:
[]
Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond end
of device
Apr 8 02:46:11 s9 kernel: [ 189.691787] dm-3: rw=129, want=23361976,
limit=20967424
I recently bumped into this too [1]. Liu Bo pos
On 9 April 2012 22:44, Leho Kraav wrote:
> On 09.04.2012 17:35, Daniel J Blueman wrote:
>>
>> Leho Kraav kraav.com> writes:
>> []
>>>
>>> Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond end
>>> of device
>>> Apr 8 02:46:11 s9 kernel: [ 189.691787] dm-3: rw=129, want=23361976
When testing btrfs on 3.4-rc2 with unmount directly after a test
workload, I see potential deadlock:
[ INFO: possible circular locking dependency detected ]
3.4.0-rc2-debug+ #2 Not tainted
---
fio/2365 is trying to acquire lock:
(&type->s_umount
On Wed, Apr 04, 2012 at 02:16:22PM -0400, Josef Bacik wrote:
> On Wed, Apr 04, 2012 at 09:12:57PM +0300, Kasatkin, Dmitry wrote:
> > On Wed, Apr 4, 2012 at 8:47 PM, Mimi Zohar wrote:
> > > On Wed, 2012-04-04 at 13:43 -0400, Josef Bacik wrote:
> > >> On Wed, Apr 04, 2012 at 08:24:19PM +0300, Kasatk
This fixes a regression introduced by fc67c450. spin_is_locked() always
returns 0 on UP kernels, which caused assert in get_restripe_target() to
be fired on every call from btrfs_reduce_alloc_profile() on UP systems.
Remove it completely for now, it's not clear if it's going to be needed
in future
We've been keeping around the inode sequence number in hopes that somebody
would use it, but nobody uses it and people actually use i_version which
serves the same purpose, so use i_version where we used the incore inode's
sequence number and that way the sequence is updated properly across the
boa
On Mon, Apr 9, 2012 at 9:53 AM, Calvin Walton wrote:
> Hi,
>
> I have a system that's using a dracut-generated initramfs to mount a
> btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've
> noticed that the process of mounting the root filesystem takes much
> longer with 3.4.0-rc2 t
On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
> Hi,
>
> I have a system that's using a dracut-generated initramfs to mount a
> btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've
> noticed that the process of mounting the root filesystem takes much
> longer with 3.4.0-rc
On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
> On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
> > Hi,
> >
> > I have a system that's using a dracut-generated initramfs to mount a
> > btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've
> > noticed that th
Am Montag, 9. April 2012 schrieb Daniel J Blueman:
> On 9 April 2012 22:44, Leho Kraav wrote:
> > On 09.04.2012 17:35, Daniel J Blueman wrote:
> >> Leho Kraav kraav.com> writes:
> >> []
> >>
> >>> Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond
> >>> end of device
> >>> Apr
The new xfstests will run fsck against the volume to make sure we didn't
introduce any inconsistencies, which is nice except we will error out
immediately if we mount with inode_cache. We need to make btrfsck skip the
special free space cache items and then just assume that we have a link for
the
On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
> On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
> > Hi,
> >
> > I have a system that's using a dracut-generated initramfs to mount a
> > btrfs root. After upgrading to kernel 3.4.0-rc2 to test it out, I've
> > noticed that th
On 09.04.2012 17:54, Daniel J Blueman wrote:
On 9 April 2012 22:44, Leho Kraav wrote:
And is the previous filesystem still hosed for good then? Or mounting the
images with -discard might help?
It seems like the kernel caught and prevented the discard after the
end of the partition, so the da
On Mon, 2012-04-09 at 16:54 -0400, Josef Bacik wrote:
> On Mon, Apr 09, 2012 at 01:10:04PM -0400, Calvin Walton wrote:
> > On Mon, 2012-04-09 at 11:53 -0400, Calvin Walton wrote:
> > > Hi,
> > >
> > > I have a system that's using a dracut-generated initramfs to mount a
> > > btrfs root. After upgr
On 09.04.2012 23:58, Leho Kraav wrote:
On 09.04.2012 17:54, Daniel J Blueman wrote:
On 9 April 2012 22:44, Leho Kraav wrote:
And is the previous filesystem still hosed for good then? Or mounting
the
images with -discard might help?
It seems like the kernel caught and prevented the discard af
Greetings,
I am testing the 3.4.0(rc) btrfs patches backported to a 3.3.1 kernel.
I'm particularly interested in the large metadata features for help
with fragmentation issues. After merging, installing, and booting the
new kernel, I created several btrfs filesystems with leaf size 32768
and nod
On Mon, Apr 09, 2012 at 04:06:56PM -0600, Calvin Morrow wrote:
> After a reboot however, the "flagging fs with big metadata feature"
> message no longer appears on subsequent mounts.
/*
* flag our filesystem as having big metadata blocks if
* they are bigger than the page
On Mon, Apr 09, 2012 at 09:37:08AM +0800, Liu Bo wrote:
> The whole thing is about our overcommit stuff, that is,
> since we are not able to get _precise_ number of reservation right now, we
> usually
> reserve more than what we need.
> For this, we've done overcommit dance (thanks for Josef's wor
On Tue, Apr 10, 2012 at 12:32:00AM +0300, Leho Kraav wrote:
> It is also BUG time WITH the patch. Mount succeeds, but "btrfs fi balance
> HOME" gives us:
>
> Apr 10 00:24:18 server sudo: pam_unix(sudo:session): session opened for user
> > root by (uid=1000)
> Apr 10 00:24:18 server kernel: [ 363
Hello,
I just wanted to ask if storing metadata on a dedicated device is
implemented at the moment ?
It's listed under "Project ideas" and there is supposed to be a patch
but I can't find it anywhere.
Greetings
Jan Killius
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" i
24 matches
Mail list logo
