Thank you guys for this status ! I think you should add it somewhere in the
documentation cause I'm pretty sure this is a repeated question from users.
--
Cyril SCETBON
> On 06 Nov 2014, at 02:51, Qu Wenruo wrote:
>
>
> Original Message
> Subject: Re: Compatibility matrix ke
Hi,
On 05/11/14 21:14, Milosz Tanski wrote:
From: Christoph Hellwig
Clean up the generic_write_sync by just passing an iocb and a bytes
written / negative errno argument. In addition to simplifying the
callers this also prepares for passing a per-operation O_DSYNC
flag. Two callers didn't qu
Hello,
I got a warning from the kbuild test robot for an invalid address
space cast, which was introduced by my patch for TREE_SEARCH_V2. Here
is a patch, which should fix the warning.
Regards,
Gerhard
2014-11-06 10:48 GMT+01:00 kbuild test robot :
> tree: git://git.kernel.org/pub/scm/linux/
Hi,
> On 5 Nov 2014, at 23:14, Milosz Tanski wrote:
>
> From: Christoph Hellwig
>
> Clean up the generic_write_sync by just passing an iocb and a bytes
> written / negative errno argument. In addition to simplifying the
> callers this also prepares for passing a per-operation O_DSYNC
> flag.
On Wed 05-11-14 16:14:52, Milosz Tanski wrote:
> From: Christoph Hellwig
>
> Clean up the generic_write_sync by just passing an iocb and a bytes
> written / negative errno argument. In addition to simplifying the
> callers this also prepares for passing a per-operation O_DSYNC
> flag. Two calle
INFO: task jhead:16654 blocked for more than 120 seconds.
Tainted: GW O 3.16.3-amd64-i915-preempt-20140714fm1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
jhead D 8802f7e6d060 0 16654 15616 0x20020080
88023c797d00 0
On 11/04/2014 05:26 AM, Miao Xie wrote:
On Mon, 3 Nov 2014 08:56:50 -0500, Josef Bacik wrote:
Our gluster boxes get several thousand statfs() calls per second, which begins
to suck hardcore with all of the lock contention on the chunk mutex and dev list
mutex. We don't really need to hold these
On 10/23/2014 04:44 AM, Miao Xie wrote:
On Thu, 18 Sep 2014 11:27:17 -0400, Josef Bacik wrote:
Trying to reproduce a log enospc bug I hit a panic in the async reclaim code
during log replay. This is because we use fs_info->fs_root as our root for
shrinking and such. Technically we can use what
My rootfs on /dev/sda2 (an SSD) shows this:
Nov 06 15:37:26 hiro.oops.intern kernel: BTRFS critical (device sda2):
corrupt leaf, slot offset bad: block=100235100160,root=1, slot=142
Scrub runs through fine:
# btrfs scr stat /dev/sda2
scrub status for ea95dbd1-ef4e-48a4-9732-54e6c80b31df
Hi guys,
I need to improve the backup strategy of my vms; At the moment I backup the
machines once a week by stopping them, making a snapshot, exporting the xml
descriptor file and backing up these files.
I would prefer a daily online backup solution that allows me to take a snapshot
with a mi
If we have two fsync()'s race on different subvols one will do all of its work
to get into the log_tree, wait on it's outstanding IO, and then allow the
log_tree to finish it's commit. The problem is we were just free'ing that
subvols logged extents instead of waiting on them, so whoever lost the
Am 06.11.2014 um 15:45 schrieb Stefan G. Weichinger:
> Pls advise how to proceed.
>
> Should I do some repair or btrfsck from a live-medium?
... had some hefty kernel crashes ...
Now I am on latest sysresccd.
btrfsck v 3.16 ... fails as well
Backing up.
Seems I have to recreate the btrfs (wi
On Thu, Nov 6, 2014 at 5:52 AM, Anton Altaparmakov wrote:
> Hi,
>
>> On 5 Nov 2014, at 23:14, Milosz Tanski wrote:
>>
>> From: Christoph Hellwig
>>
>> Clean up the generic_write_sync by just passing an iocb and a bytes
>> written / negative errno argument. In addition to simplifying the
>> call
Am 06.11.2014 um 17:11 schrieb Stefan G. Weichinger:
> Am 06.11.2014 um 15:45 schrieb Stefan G. Weichinger:
>
>> Pls advise how to proceed.
>>
>> Should I do some repair or btrfsck from a live-medium?
>
> ... had some hefty kernel crashes ...
>
> Now I am on latest sysresccd.
>
> btrfsck v 3.16
Copied a tarball of btrfs-progs v 3.17-r1 over and ran:
btrfs check --repair /dev/sda2
it tells me
incorrect offsets 12499 blabla
items overlap, can't fix
cmds-check.c:2918 fix_item_offset: Assertion `ret` failed
... and crashes
Any help appreciated!
--
To unsubscribe from this list: send t
restoring from backup now
--
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 http://vger.kernel.org/majordomo-info.html
Dear user,
Your mailbox has Exceeded the quota limit set by the administrator, you will
not be able to send or receive mailuntil you revalidates your account.
Please click the link below or copy paste to your browser to validate your
mailbox.
http://www.urlme.co/quota-service
Failure to do
On Nov 6, 2014, at 8:02 AM, Francesco Morosinotto wrote:
> Hi guys,
>
> I need to improve the backup strategy of my vms; At the moment I backup the
> machines once a week by stopping them, making a snapshot, exporting the xml
> descriptor file and backing up these files.
>
> I would prefer a
A few days ago, I started using rsync batches to archive old copies of
ceph OSD snapshots for certain kinds of disaster recovery. This seems
to exercise an unexpected race condition in rsync, which happens to
expose what appears to be a race condition in btrfs, causing random
scary but harmless er
On Thu, 6 Nov 2014 09:39:19 -0500, Josef Bacik wrote:
> On 10/23/2014 04:44 AM, Miao Xie wrote:
>> On Thu, 18 Sep 2014 11:27:17 -0400, Josef Bacik wrote:
>>> Trying to reproduce a log enospc bug I hit a panic in the async reclaim code
>>> during log replay. This is because we use fs_info->fs_root
[dropping rs...@lists.samba.org, it rejects posts from non-subscribers;
refer to https://bugzilla.samba.org/show_bug.cgi?id=10925 instead]
On Nov 6, 2014, Alexandre Oliva wrote:
> What makes the problem visible is that btrfs appears to have a race in
> its handling of xattr replacement, leavin
There is no need to try to build seed/sprout mapping for those btrfs
without seed devices, so just skip such fs.
We could get the total number of devices from the disk super block, if it
equals the number of items in list @fs_devices->devices, then there shouldn't
be any seed devices.
Signed-off-b
The @fi_args->num_devices in @get_fs_info() does not include seed devices.
We could just correct it by searching the chunk tree and count how
many dev_items there are in total which includes seed devices.
Signed-off-by: Gui Hecheng
---
*Note*
This is just a temporary workaround to fix this proble
The following BUG_ON:
BUG_ON(ndevs >= fi_args->num_devices)
is not needed, because it always fails with seed devices present.
Signed-off-by: Gui Hecheng
---
utils.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/utils.c b/utils.c
index f10c178..9bcc1a0 100644
--- a/utils.c
+++ b/util
Cyril Scetbon posted on Thu, 06 Nov 2014 10:21:47 +0100 as excerpted:
>>> On Wed, Nov 05, 2014 at 09:57:31PM +0100, Cyril Scetbon wrote:
Where can I find the compatibility matrix to know which btrfs-tools
version should work with a chosen linux kernel ?
> Thank you guys for this s
25 matches
Mail list logo
