Sorry about emailing the list about this but after doing some googling i
can't seem to find the answer.
Im just wondering if subvolumes or snap shot can have quotas imposed on
them.
The wiki says that:
"Subvolumes can be given a quota of blocks, and once this quota is
reached no new writes are a
I got namespace.pl working again, and it showed the following
routines could be declared static.
fs/btrfs/ctree
btrfs_clear_path_blocking
btrfs_insert_some_items
btrfs_prev_leaf
fs/btrfs/delayed-ref
btrfs_delayed_ref_pending
fs/btrfs/dir-item
btrfs_match_dir_item_name
f
Running with lockdep I see these warnings (running 2.6.37-rc1)
It occurred during the time when rsync is running backup.
Nov 14 12:03:31 nehalam kernel: [ 5527.284541]
=
Nov 14 12:03:31 nehalam kernel: [ 5527.284544] [ INFO: possible recursive
lockin
Setup new 60G home partition on laptop as a real life test of 0.16.
Using Ubuntu standard kernel 2.6.24-19-generic on i386
I notice that during normal (busy time) everything seems fine, but after going
away
for a while and coming back, it seems sluggish. Lots of errors in log:
btrfs csum failed
On Thu, 14 Aug 2008 06:25:14 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-08-14 at 00:11 -0700, Stephen Hemminger wrote:
> > Setup new 60G home partition on laptop as a real life test of 0.16.
> > Using Ubuntu standard kernel 2.6.24-19-generic on i386
> &
On Thu, 14 Aug 2008 13:26:00 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-08-14 at 09:19 -0700, Stephen Hemminger wrote:
> > On Thu, 14 Aug 2008 06:25:14 -0400
> > Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 2008-08-
On Thu, 14 Aug 2008 14:21:22 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-08-14 at 11:06 -0700, Stephen Hemminger wrote:
>
> > > So, the question is why the kernel compile workload works for me. What
> > > kind of hardware are you running (ram, cpu,
On Mon, 8 Sep 2008 16:20:52 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > The idea is to try to spin for a bit to avoid scheduling away, which is
> > > > especially importa
On Mon, 8 Sep 2008 17:47:14 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> > On Mon, 8 Sep 2008 16:20:52 +0200
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Sep 08, 2
On Mon, 08 Sep 2008 12:20:32 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote:
> > Chris Mason wrote:
> > >> My guess is that the improvement happens mostly from the first couple of
> > >> tries,
> > >> not from repeated spinning. And since it is a
On Wed, 29 Oct 2008 14:02:04 -0600
Joe Peterson <[EMAIL PROTECTED]> wrote:
> Chris Mason wrote:
> > On Tue, 2008-10-28 at 16:48 -0700, Stephen Hemminger wrote:
> >> I have a system with a pair of small/fast but unreliable scsi drives.
> >> I tried setting up a rai
x-next, yet? Or
is this more -mm material?
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpXCczZEg3KS.pgp
Description: PGP signature
On Wed, 10 Dec 2008 20:06:04 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I'd prefer that it go into linux-next in the usual fashion. But the
> first step is review..
OK, I wasn't sure where it was up to (not being a file system person).
--
Hi,
Find instructions on how to recreate below -
I have a BTRFS raid 10 setup in Virtualbox (I'm getting to grips with
the Filesystem)
I have the raid mounted to /mnt like so -
[root@Xen ~]# btrfs filesystem show /mnt/
Label: none uuid: ad1d95ee-5cdc-420f-ad30-bd16158ad8cb
Total devic
see this quite a
lot where a drive is beyond dead - The OS will literally not detect it.
At this point would the Raid10 array be beyond repair? As you need the
drive present in order to mount the array in degraded mode.
--
Stephen Williams
steph...@veryfast.biz
On Fri, Mar 25, 2016, at 02:57
admins crying over this.
--
Stephen Williams
steph...@veryfast.biz
On Sat, Mar 26, 2016, at 11:51 AM, Patrik Lundquist wrote:
> So with the lessons learned:
>
> # mkfs.btrfs -m raid10 -d raid10 /dev/sdb /dev/sdc /dev/sdd /dev/sde
>
> # mount /dev/sdb /mnt; dmesg | tail
>
Yeah I think the Gotchas page would be a good place to give people a
heads up.
--
Stephen Williams
steph...@veryfast.biz
On Sat, Mar 26, 2016, at 09:58 PM, Chris Murphy wrote:
> On Sat, Mar 26, 2016 at 8:00 AM, Stephen Williams
> wrote:
>
> > I know this is quite a rare
fpaste.org/9383/36729191/
My setup is two 2TB hard drives in raid 1. They are both sata drives so
as far as I know the USB disconnect line isn't referring to btrfs.
output of df -h:
/dev/sdb1 3.7T 3.2T 371G 90% /mount/point
I haven't figured out how to reproduce the bug.
-- Stephen
--
To u
tree?
>
> I can see 3 potential options:
>
> 1) I could just pull these into the branch that Stephen is already
> picking up for file-locks in my tree
>
> 2) I could put them into a new branch, and have Stephen pull that one in
> addition to the file-locks branch
>
>
xt-merge
Thanks for that. It seems to have merged OK but maybe it conflicts
with something later in linux-next. Unfortunately see my other email
about a build problem. I will keep this example merge in mind for
later.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To u
#x27;s not documented. Can someone tell me where to find a list of
feature priorities or when this might be done.
Thank you,
Stephen
--
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 ht
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git next
>
> I've got the sample resolution in next-merge:
>
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git next-merge
>
> Please let us know if you have any problems.
A bit of a mess, b
All:
I came back to my computer yesterday to find my filesystem in read only
mode. Running a btrfs scrub start -dB aborts as follows:
btrfs scrub start -dB /mnt
ERROR: scrubbing /mnt failed for device id 4: ret=-1, errno=5
(Input/output error)
ERROR: scrubbing /mnt failed for device id 5: ret
On 10/3/2017 2:11 PM, Hugo Mills wrote:
Hi, Stephen,
On Tue, Oct 03, 2017 at 08:52:04PM +, Stephen Nesbitt wrote:
Here it i. There are a couple of out-of-order entries beginning at 117. And
yes I did uncover a bad stick of RAM:
btrfs-progs v4.9.1
leaf 2589782867968 items 134 free
led? I am led to
> understand that SELinux has worked around this, but looking at
> the SELinux code I expect that there is a problem there as well.
>
> Thank you.
kernel version(s)?
reproducer?
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this lis
On Thu, 2011-04-28 at 10:03 -0700, Casey Schaufler wrote:
> On 4/28/2011 6:30 AM, Stephen Smalley wrote:
> > On Tue, 2011-04-26 at 20:15 -0700, Casey Schaufler wrote:
> >> I have been tracking down an problem that we've been seeing
> >> with Smack on top of btrf
On Thu, 2011-04-28 at 13:13 -0400, Stephen Smalley wrote:
> On Thu, 2011-04-28 at 10:03 -0700, Casey Schaufler wrote:
> > On 4/28/2011 6:30 AM, Stephen Smalley wrote:
> > > On Tue, 2011-04-26 at 20:15 -0700, Casey Schaufler wrote:
> > >> I have been tracking down an
/btrfs/sysfs.c:153:13: warning: 'btrfs_super_release' defined but not used
fs/btrfs/sysfs.c:160:13: warning: 'btrfs_root_release' defined but not used
I have started using gcc v4.5.2 (instead of v4.4.4) if that makes a
difference.
--
Cheers,
Stephen Rothwell
ebc0f93dc692b734c12665a6824d219c20
> >>
> >> https://github.com/markus-oberhumer/linux/commit/10f6781c8591fe5fe4c8c733131915e5ae057826
> >>
> >> https://github.com/markus-oberhumer/linux/commit/5f702781f158cb59075cfa97e5c21f52275057f1
> >
> > The changes look OK to me. Pleas
I can immediately
try any proposed patches or fixes (or provide more insight into the
subvolume this problem occurs with).
Numerous other subvolumes in the same BTRFS partition work flawlessly
using btrfs send/receive.
The sending partition is RAID0 with two 512GB SSD drives. The receiving
partiti
Stephen R. van den Berg wrote:
>I'm running 4.4.0-rc7.
>This exact problem was present on 4.0.5 and 4.3.3 too though.
>I do a "btrfs send /var/lib/lxc/template64/rootfs", that generates
>the following error consistently at the same file, over and over again:
>Dec 2
ent+0xd3/0x105
Dec 9 10:41:34 argos kernel: ? finish_wait+0x60/0x60
Dec 9 10:43:37 argos kernel: INFO: task btrfs:409 blocked for more than 120
seconds.
Dec 9 10:43:37 argos kernel: Not tainted
94.19.7-srb-asrock-1-g22c8f45edcaf #137
Dec 9 10:43:37 argos kernel: ? finish_wait+0x60/0x60
Dec 9 12:08:42 argos kernel: Code: 1f 80 00 00 00 00 e9 7b ff ff ff 66 2e 0f
1f 84 00 00 00 00 00 90 48 81 ec f8 ff 00 00 8b 05 8f 2e 00 00 48 8d 35 40 0e
00 00 <48> 89 3c 24 48 8b 3d 81 2e 00 00 8d 90 00 00 01 00 31 c0 89 15 6f
--
Stephen.
evious btrfs-receive is still
late flushing buffers to disk when the new btrfs-receive already starts).
--
Stephen.
Chris Murphy wrote:
>Also, what scheduler are you using? And do you get different results
>with a different one (better or worse)?
I'm using CFQ, and I don't think I ever tried a different one.
But, btrfs should be compatible with all schedulers.
--
Stephen.
Chris Murphy wrote:
>On Wed, Dec 12, 2018 at 12:26 AM Stephen R. van den Berg wrote:
>> I'm using CFQ, and I don't think I ever tried a different one.
>> But, btrfs should be compatible with all schedulers.
>But yeah, one of the developers might have more to say abou
either disable qgroup or apply this patch to solve it:
>https://patchwork.kernel.org/patch/10725371/
Any idea in which kernel version this patch is/will be included?
--
Stephen.
Qu Wenruo wrote:
>On 2018/12/28 ??9:40, Stephen R. van den Berg wrote:
>>> It's caused by qgroup, and a dead lock on btrfs_drop_snapshot().
>>> This is one of the easiest way to trigger an ABBA deadlock.
>>> Please either disable qgroup or appl
that patch https://patchwork.kernel.org/patch/10725371/
(qgroup: Don't trigger backref walk at delayed ref insert time)
is present in mainline Linux kernel v5.2.2 ?
I seem to be getting a conflict on merging that patch with this kernel.
--
Stephen.
Stephen R. van den Berg wrote:
>Qu Wenruo wrote:
>>On 2018/12/28 ??????9:40, Stephen R. van den Berg wrote:
>>>> It's caused by qgroup, and a dead lock on btrfs_drop_snapshot().
>>>> This is one of the easiest way to trigger an ABBA deadlock.
>>>>
Stephen R. van den Berg wrote:
>Stephen R. van den Berg wrote:
>>Qu Wenruo wrote:
>>>>> It's caused by qgroup, and a dead lock on btrfs_drop_snapshot().
>>>>> Please either disable qgroup or apply this patch to solve it:
>>>>> https://pat
Stephen R. van den Berg wrote:
>Stephen R. van den Berg wrote:
>>Stephen R. van den Berg wrote:
>>>Qu Wenruo wrote:
>>>>>> It's caused by qgroup, and a dead lock on btrfs_drop_snapshot().
>>>>>> Please either disable qgroup or apply
Are these Sysreq+w dumps not usable?
--
Stephen.
42 matches
Mail list logo
