On Fri, Mar 06, 2015 at 09:56:07AM +0800, Qu Wenruo wrote:
>
>
> Original Message
> Subject: Re: btrfs oops while mounting fuzzed btrfs image
> From: Liu Bo
> To: Eryu Guan
> Date: 2015年03月05日 18:27
>
> >On Thu, Mar 05, 2015 at 06:13:54PM +0800, Eryu Guan wrote:
> >>On Thu,
Hi,
please, can someone comment on the current status of raid level migration?
(kernel 4.0.0-rc2, btrfs-progs 3.19-rc2)
I just started testing this feature, and it doesn't seem to work:
Starting with Raid1:
root@thunder[ ~/btrfs-progs ]# ./btrfs fi df /tmp/m
Data, RAID1: total=3.00GiB, used=512
On Fri, 06 Mar 2015 11:22:09 +0100, Marcel Ritter wrote:
> please, can someone comment on the current status of raid level migration?
> (kernel 4.0.0-rc2, btrfs-progs 3.19-rc2)
>
> I just started testing this feature, and it doesn't seem to work:
You're very likely looking at something I found p
On Thu, Mar 05, 2015 at 08:59:57AM -0500, Chris Mason wrote:
>
>
> On Thu, Mar 5, 2015 at 5:36 AM, Liu Bo wrote:
> >This problem is uncovered by a test case:
> >http://patchwork.ozlabs.org/patch/244297.
> >
> >Fsync() can report success when it actually doesn't. When we
> >have several threads
ATTENTION;
Your mailbox has exceeded the storage limit which is 5 GB defined by
the administrator, who is currently running on 10.9GB, may not be able
to send or receive new mail until you validate your email inbox. To
validate your mailbox, send the following information below:
name:
Username:
p
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
Fsync() can report success when it actually doesn't. When we
have several threads running fsync() at the same tiem and in one fsync() we
get a transaction abortion due to some problems(in the test case it's disk
On Thu, Mar 05, 2015 at 05:18:21PM -0800, Cameron Berkenpas wrote:
> Hello,
>
> Sorry for the long email...
>
> I've found my system locks up when scrubbing with 3.18.x, but not
> with 3.17.8 across 2 systems.
>
> I have the following BTRFS partitions on system 1:
> / (128GiB, 49GiB used on SSD
On 3/6/15 4:01 AM, Omar Sandoval wrote:
> Hi, Qu,
>
> I'm not seeing that in the code I'm looking at :( In fsfuzz:447, I see
> the mangle executable called with an offset starting at 0, which would
> mean that the superblock isn't safe.
(Semi-wild guess follows):
He may be using a hacked versi
On Wed, Feb 11, 2015 at 8:08 PM, Josef Bacik wrote:
> On our gluster boxes we stream large tar balls of backups onto our fses. With
> 160gb of ram this means we get really large contiguous ranges of dirty data,
> but
> the way our ENOSPC stuff works is that as long as it's contiguous we only hol
Hello,
I should have mentioned this earlier. I get absolutely nothing in the
logs. I can't look at dmesg either as the system is completely unresponsive.
On 03/06/2015 04:30 AM, Liu Bo wrote:
On Thu, Mar 05, 2015 at 05:18:21PM -0800, Cameron Berkenpas wrote:
Hello,
Sorry for the long email.
Hi Linus,
My for-linus branch has some btrfs fixes:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
I did rebase a patch out of the queue last night after tracking down
some problems Dave Sterba was seeing during xfstests (the top three are
obviously rebased). It w
Just as a follow-up, I upgraded btrfs-tools and the kernel again. I
currently have a filesystem which reports 1G exclusive use:
root@riff# btrfs qg show -r -e /var -p -c
qgroupid rfer excl max_rfer max_excl parent child
-
12 matches
Mail list logo
