Hi Chris,
Thanks for your response :).
On 21 October 2016 at 05:18, Chris Murphy wrote:
> On Thu, Oct 20, 2016 at 3:20 PM, Suvayu Ali
> wrote:
>> Hi,
>>
>> (please CC me in replies, I'm not subscribed)
>>
>> I'm using kernel 4.7.7-100.fc23 with btrfs-progs v4.7.1.
>>
>> I had my /home, /var, a
On 10/21/2016 11:00 AM, Darrick J. Wong wrote:
On Thu, Oct 20, 2016 at 08:47:33AM -0700, Omar Sandoval wrote:
On Thu, Oct 20, 2016 at 03:50:46PM +0800, Qu Wenruo wrote:
Add cc to new xfs mail list.
At 10/20/2016 03:46 PM, Qu Wenruo wrote:
Hi Darrick, xfs guys and btrfs guys.
Although such
On Thu, Oct 20, 2016 at 08:47:33AM -0700, Omar Sandoval wrote:
> On Thu, Oct 20, 2016 at 03:50:46PM +0800, Qu Wenruo wrote:
> > Add cc to new xfs mail list.
> >
> >
> > At 10/20/2016 03:46 PM, Qu Wenruo wrote:
> > > Hi Darrick, xfs guys and btrfs guys.
> > >
> > > Although such question is quite
On Thu, Oct 20, 2016 at 3:20 PM, Suvayu Ali wrote:
> Hi,
>
> (please CC me in replies, I'm not subscribed)
>
> I'm using kernel 4.7.7-100.fc23 with btrfs-progs v4.7.1.
>
> I had my /home, /var, and /opt as subvolumes in a btrfs partition.
> Last night btrfs failed, and I was unable to mount it nor
On Thu, Oct 20, 2016 at 4:03 PM, Dave Jones wrote:
> On Thu, Oct 20, 2016 at 04:01:12PM -0700, Andy Lutomirski wrote:
> > On Thu, Oct 20, 2016 at 3:50 PM, Dave Jones
> wrote:
> > > On Tue, Oct 18, 2016 at 06:05:57PM -0700, Andy Lutomirski wrote:
> > >
> > > > One possible debugging approach
On Thu, Oct 20, 2016 at 04:01:12PM -0700, Andy Lutomirski wrote:
> On Thu, Oct 20, 2016 at 3:50 PM, Dave Jones wrote:
> > On Tue, Oct 18, 2016 at 06:05:57PM -0700, Andy Lutomirski wrote:
> >
> > > One possible debugging approach would be to change:
> > >
> > > #define NR_CACHED_STACKS 2
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
master
head: 570b2b152bf32db746eb6de1a144491b5f7ca34f
commit: 3bfb81930e877c80af87a9954ca5714aa6ae60ee [3/11] writeback: allow for
dirty metadata accounting
config: x86_64-randconfig-i0-201642 (attached as .config)
com
On Thu, Oct 20, 2016 at 3:50 PM, Dave Jones wrote:
> On Tue, Oct 18, 2016 at 06:05:57PM -0700, Andy Lutomirski wrote:
>
> > One possible debugging approach would be to change:
> >
> > #define NR_CACHED_STACKS 2
> >
> > to
> >
> > #define NR_CACHED_STACKS 0
> >
> > in kernel/fork.c and to
On Tue, Oct 18, 2016 at 06:05:57PM -0700, Andy Lutomirski wrote:
> One possible debugging approach would be to change:
>
> #define NR_CACHED_STACKS 2
>
> to
>
> #define NR_CACHED_STACKS 0
>
> in kernel/fork.c and to set CONFIG_DEBUG_PAGEALLOC=y. The latter will
> force an immediate
On Tue, Oct 18, 2016 at 05:28:44PM -0700, Linus Torvalds wrote:
> On Tue, Oct 18, 2016 at 5:10 PM, Linus Torvalds
> wrote:
> >
> > Adding Andy to the cc, because this *might* be triggered by the
> > vmalloc stack code itself. Maybe the re-use of stacks showing some
> > problem? Maybe Chris (
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
master
head: 570b2b152bf32db746eb6de1a144491b5f7ca34f
commit: 3bfb81930e877c80af87a9954ca5714aa6ae60ee [3/11] writeback: allow for
dirty metadata accounting
config: i386-randconfig-s0-201642 (attached as .config)
compi
Hi,
(please CC me in replies, I'm not subscribed)
I'm using kernel 4.7.7-100.fc23 with btrfs-progs v4.7.1.
I had my /home, /var, and /opt as subvolumes in a btrfs partition.
Last night btrfs failed, and I was unable to mount it normally
(leading to boot failures). The journal had messages like
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
master
head: 570b2b152bf32db746eb6de1a144491b5f7ca34f
commit: 2d700e7883ba3aad07fa80214b66ed142cbc5ecc [9/11] Btrfs: kill the
btree_inode
config: x86_64-randconfig-x015-201642 (attached as .config)
compiler: gcc-6 (Deb
On 2016-10-20 13:33, ronnie sahlberg wrote:
On Thu, Oct 20, 2016 at 7:44 AM, Austin S. Hemmelgarn
wrote:
On 2016-10-20 09:47, Timofey Titovets wrote:
2016-10-20 15:09 GMT+03:00 Austin S. Hemmelgarn :
On 2016-10-20 05:29, Timofey Titovets wrote:
Hi, i use btrfs for NFS VM replica storage
On Thu, Oct 20, 2016 at 7:44 AM, Austin S. Hemmelgarn
wrote:
> On 2016-10-20 09:47, Timofey Titovets wrote:
>>
>> 2016-10-20 15:09 GMT+03:00 Austin S. Hemmelgarn :
>>>
>>> On 2016-10-20 05:29, Timofey Titovets wrote:
Hi, i use btrfs for NFS VM replica storage and for NFS shared VM
>
On 2016-10-20 11:26, Roman Mamedov wrote:
On Thu, 20 Oct 2016 08:09:14 -0400
"Austin S. Hemmelgarn" wrote:
So, it's possible to return unlink() early? or this a bad idea(and why)?
I may be completely off about this, but I could have sworn that unlink()
returns when enough info is on the disk
On Thu, Oct 20, 2016 at 03:50:46PM +0800, Qu Wenruo wrote:
> Add cc to new xfs mail list.
>
>
> At 10/20/2016 03:46 PM, Qu Wenruo wrote:
> > Hi Darrick, xfs guys and btrfs guys.
> >
> > Although such question is quite late as reflink generic tests are in
> > fstests for a long time, I'm still no
On Thu, 20 Oct 2016 08:09:14 -0400
"Austin S. Hemmelgarn" wrote:
> > So, it's possible to return unlink() early? or this a bad idea(and why)?
> I may be completely off about this, but I could have sworn that unlink()
> returns when enough info is on the disk that both:
> 1. The file isn't actual
On 2016-10-20 09:47, Timofey Titovets wrote:
2016-10-20 15:09 GMT+03:00 Austin S. Hemmelgarn :
On 2016-10-20 05:29, Timofey Titovets wrote:
Hi, i use btrfs for NFS VM replica storage and for NFS shared VM storage.
At now i have a small problem what VM image deletion took to long time
and NFS c
2016-10-20 15:09 GMT+03:00 Austin S. Hemmelgarn :
> On 2016-10-20 05:29, Timofey Titovets wrote:
>>
>> Hi, i use btrfs for NFS VM replica storage and for NFS shared VM storage.
>> At now i have a small problem what VM image deletion took to long time
>> and NFS client show a timeout on deletion
>>
On 2016-10-20 05:29, Timofey Titovets wrote:
Hi, i use btrfs for NFS VM replica storage and for NFS shared VM storage.
At now i have a small problem what VM image deletion took to long time
and NFS client show a timeout on deletion
(ESXi Storage migration as example).
Kernel: Linux nfs05 4.7.0-0
Just updated my kernel and btrfs-tools to 4.8.1 and now it seems
that "btrfs quota rescan -w " does not in fact wait
for the rescan to finish. Running it a second time immediately
after does, however.
Was this an intentional change, or is it a regression/bug?
--
twalb...@gmail.com, twalb...@com
On 10/20/2016 05:35 PM, Qu Wenruo wrote:
At 10/20/2016 05:23 PM, Sanidhya Solanki wrote:
On Mon, 17 Oct 2016 09:27:31 +0800
Qu Wenruo wrote:
For READ, caller normally hopes to get what they request, other than
full stripe map.
In this case, we should remove unrelated stripe map, just lik
At 10/20/2016 05:20 PM, David Sterba wrote:
On Thu, Oct 20, 2016 at 09:05:34AM +0800, Qu Wenruo wrote:
At 10/19/2016 10:31 PM, David Sterba wrote:
On Fri, Sep 30, 2016 at 09:15:36AM +0800, Qu Wenruo wrote:
While the reason why qgroup reserved space may underflow is still under
investigatio
At 10/20/2016 05:23 PM, Sanidhya Solanki wrote:
On Mon, 17 Oct 2016 09:27:31 +0800
Qu Wenruo wrote:
For READ, caller normally hopes to get what they request, other than
full stripe map.
In this case, we should remove unrelated stripe map, just like the
following case:
32K
Hi, i use btrfs for NFS VM replica storage and for NFS shared VM storage.
At now i have a small problem what VM image deletion took to long time
and NFS client show a timeout on deletion
(ESXi Storage migration as example).
Kernel: Linux nfs05 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.5-1~bpo8+2
(2016
On Mon, 17 Oct 2016 09:27:31 +0800
Qu Wenruo wrote:
> For READ, caller normally hopes to get what they request, other than
> full stripe map.
>
> In this case, we should remove unrelated stripe map, just like the
> following case:
>32K 96K
>|<-reques
On Thu, Oct 20, 2016 at 09:05:34AM +0800, Qu Wenruo wrote:
>
>
> At 10/19/2016 10:31 PM, David Sterba wrote:
> > On Fri, Sep 30, 2016 at 09:15:36AM +0800, Qu Wenruo wrote:
> >> While the reason why qgroup reserved space may underflow is still under
> >> investigation, such WARN_ON will help us to
Add cc to new xfs mail list.
At 10/20/2016 03:46 PM, Qu Wenruo wrote:
Hi Darrick, xfs guys and btrfs guys.
Although such question is quite late as reflink generic tests are in
fstests for a long time, I'm still not sure what's the correct behavior
for reflink len = 0.
Test case generic/182 is
Hi Darrick, xfs guys and btrfs guys.
Although such question is quite late as reflink generic tests are in
fstests for a long time, I'm still not sure what's the correct behavior
for reflink len = 0.
Test case generic/182 is causing different output between btrfs and xfs.
For btrfs, dedupe wi
On Thu, 20 Oct 2016, Ingo Molnar wrote:
> * Linus Torvalds wrote:
> > So I don't think it's related. Yours looks like some subtle timer base
> > race. It smells like a locking problem with timers. I'm not seeing
> > what it might be, but it *might* have been fixed by doing the
> > TIMER_MIGRATING
31 matches
Mail list logo
