Wang Shilong posted on Fri, 21 Feb 2014 10:30:25 +0800 as excerpted:
So my question is, why does scrub show a high (i.e. non-zero) value
for no_csum? I never enabled nodatasum or a similar option.
This should be related to btrfs free space cache, it is designed as
nocow without checksums.
On 13/02/14 18:02, Austin S Hemmelgarn wrote:
On 2014-02-13 12:33, Chris Murphy wrote:
On Feb 13, 2014, at 1:50 AM, Frank Kingswood fr...@kingswood-consulting.co.uk
wrote:
On 12/02/14 17:13, Saint Germain wrote:
Ok based on your advices, here is what I have done so far to use UEFI
(remeber
First of all, I am sorry that I screw up the whole structure of the discussion
(I have not subscribed to the mailing list, and as Kai replied to the mailing
list only, I could not reply to his answer.)
Kai: Yeah, your point was neutral and I did never understand it otherwise.
Thank you for
I'm currently running kernel 3.13.3 with Chris's for-linus merged in
(up to commit 93de4ba86480a9e0d1062cb1d535fa97fb81af48). After about
a day of heavy IO I'll start to see the following in my kernel log:
[3.454967] INFO: task qemu-system-x86:27673 blocked for more than
120 seconds.
On 2/21/14, 12:07 AM, Wang Shilong wrote:
There are many places that need parse string to u64 for btrfs commands,
in fact, we do such things *too casually*, using atoi/atol/atoll..is not
right at all, and even we don't check whether it is a valid string.
Let's do everything more gracefully,
Dave posted on Fri, 21 Feb 2014 10:21:38 -0500 as excerpted:
During this time, all IO totally freezes. Atop reports no disk
activity, while my desktop is totally hung. After a few minutes
everything comes back to life, only to freeze again after a few more
minutes.
A reboot clears
Use case is a user who doesn't know that today xattr +C ought to be set on vm
images when on Btrfs. They use e.g. Gnome Boxes, or Virtual Machine Manager
(virt-manager) to configure pools, images, and VMs.
If libvirt were to set +C on any containing directory configured as a pool,
then any
On Fri, Feb 21, 2014 at 11:09 AM, Duncan 1i5t5.dun...@cox.net wrote:
One other question: Are you, or perhaps your distro via likely automated
script, doing any btrfs snapshotting of the VM-image containing btrfs
(sub)volume?
I haven't done any snapshotting on this machine.
This problem is
Chris Murphy posted on Fri, 21 Feb 2014 09:55:50 -0700 as excerpted:
Use case is a user who doesn't know that today xattr +C ought to be set
on vm images when on Btrfs. They use e.g. Gnome Boxes, or Virtual
Machine Manager (virt-manager) to configure pools, images, and VMs.
If libvirt were
On Feb 21, 2014, at 10:16 AM, Dave d...@thekilempire.com wrote:
On Fri, Feb 21, 2014 at 11:09 AM, Duncan 1i5t5.dun...@cox.net wrote:
One other question: Are you, or perhaps your distro via likely automated
script, doing any btrfs snapshotting of the VM-image containing btrfs
(sub)volume?
GEO 1g2e...@gmail.com schrieb:
First of all, I am sorry that I screw up the whole structure of the
discussion (I have not subscribed to the mailing list, and as Kai replied
to the mailing list only, I could not reply to his answer.)
Umm... Try a NNTP gateway like gmane to follow the list in
On Fri, Feb 21, 2014 at 12:59 PM, Chris Murphy li...@colorremedies.com wrote:
Five concurrent VMs for one spinning disk. It sounds like it's seeking to
death.
That's my reproducible test, not typical use.
Seeking to death would indicate drive activity. When the problem
occurs, drive activity
On Thu, Feb 20, 2014 at 01:32:34PM -0500, Josef Bacik wrote:
Yes for 3), we may also export the information through the
existing ioctls if possible (eg. IOC_FS_INFO).
For _right now_ I'd say just not do the raid56 stuff if we don't
notice any raid56 chunks from the normal
On Thu, Feb 20, 2014 at 06:08:54PM +0800, Miao Xie wrote:
@@ -1352,13 +1347,15 @@ static struct btrfs_root *alloc_log_tree(struct
btrfs_trans_handle *trans,
root-root_key.objectid = BTRFS_TREE_LOG_OBJECTID;
root-root_key.type = BTRFS_ROOT_ITEM_KEY;
root-root_key.offset =
On Thu, Feb 20, 2014 at 06:08:57PM +0800, Miao Xie wrote:
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -142,6 +142,12 @@ static int start_log_trans(struct btrfs_trans_handle
*trans,
mutex_lock(root-log_mutex);
if (root-log_root) {
+ if
On Feb 21, 2014, at 12:27 PM, Dave d...@thekilempire.com wrote:
On Fri, Feb 21, 2014 at 12:59 PM, Chris Murphy li...@colorremedies.com
wrote:
Five concurrent VMs for one spinning disk. It sounds like it's seeking to
death.
That's my reproducible test, not typical use.
Seeking to
16 matches
Mail list logo
