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, we introduce a new helper
arg_strtou64() which w
On 02/20/2014 08:38 PM, Wang Shilong wrote:
On 02/20/2014 07:25 PM, Sebastian Ochmann wrote:
Hello,
Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 as
excerpted:
So my question is, why does scrub show a high (i.e.
non-zero) value for
no_csum? I never enable
>
> - return d_obtain_alias(inode);
> + return d_obtain_alias_root(inode);
Can we call this d_obtain_root or similar, please?
--
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://vg
On Tue, Feb 18, 2014 at 03:28:58PM -0500, J. Bruce Fields wrote:
> From: "J. Bruce Fields"
>
> d_splice_alias will d_move an IS_ROOT() directory dentry into place if
> one exists. This should be safe as long as the dentry remains IS_ROOT,
> but I can't see what guarantees that: once we drop the
On Tue, Feb 18, 2014 at 03:28:57PM -0500, J. Bruce Fields wrote:
> From: "J. Bruce Fields"
>
> Just a trivial move to locate it near (similar) d_materialise_unique
> code and save some forward references in a following patch.
>
> Signed-off-by: J. Bruce Fields
Looks good,
Reviewed-by: Christo
Regression test for a btrfs incremental send issue where invalid paths for
utimes, chown and chmod operations were sent to the send stream, causing
btrfs receive to fail.
If a directory had a move/rename operation delayed, and none of its parent
directories, except for the immediate one, had delay
When doing an incremental send, if we had a directory pending a move/rename
operation and none of its parents, except for the immediate parent, were
pending a move/rename, after processing the directory's references, we would
be issuing utimes, chown and chmod intructions against am outdated path -
GEO <1g2e...@gmail.com> schrieb:
> @Kai Krakow: I accept your opinion and thank you for your answer.
> However I have special reasons doing so. I could name you a few use cases.
> For example I do not need to backup search indexes as they mess up over
> time, so I simple recreate the cache in case
Duncan <1i5t5.dun...@cox.net> schrieb:
>> Duncan had a nice example in this list how to migrate
>> directories to subvolumes by using shallow copies: "mv dir dir.old &&
>> btrfs sub create dir && cp -a -- reflink=always dir.old/. dir/. && rm
>> -Rf dir.old".
>
> FWIW, that was someone else. I r
Just comparing the pointers (logical disk addresses) of the btree nodes is
not completely bullet proof, we have to check if their generation numbers
match too.
It is guaranteed that a COW operation will result in a block with a different
logical disk address than the original block's address, but
Hi Josef,
On 02/20/2014 07:32 PM, 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 load_space_in
Hi David,
below my comments
On 02/20/2014 07:08 PM, David Sterba wrote:
> On Thu, Feb 13, 2014 at 08:18:10PM +0100, Goffredo Baroncelli wrote:
>> space (if the next chunk are allocated as SINGLE) or the minimum one (
>> if the next chunks are allocated as DUP/RAID1/RAID10).
>>
>> The other two co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2014 01:08 PM, David Sterba wrote:
> On Thu, Feb 13, 2014 at 08:18:10PM +0100, Goffredo Baroncelli
> wrote:
>> space (if the next chunk are allocated as SINGLE) or the minimum
>> one ( if the next chunks are allocated as DUP/RAID1/RAID10).
>>
On Thu, Feb 13, 2014 at 08:19:44PM +0100, Goffredo Baroncelli wrote:
>
> Allow the use of get_device_info() for different units.
FYI, I'll move this patch to integration base, it's a simple and
isolated change.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body
On Thu, Feb 13, 2014 at 08:18:10PM +0100, Goffredo Baroncelli wrote:
> space (if the next chunk are allocated as SINGLE) or the minimum one (
> if the next chunks are allocated as DUP/RAID1/RAID10).
>
> The other two commands show the chunks in the disks.
>
> $ sudo btrfs filesystem disk-usage /m
On Mon, Feb 17, 2014 at 07:09:55PM +0100, Goffredo Baroncelli wrote:
> I have to agree with Chris: looking at the output of "btrfs fi disk-usage"
>
> $ sudo ./btrfs filesystem disk-usage -t /mnt/btrfs1/
> Data DataMetadata Metadata System System
> Single RAID6
On Thu, Feb 20, 2014 at 10:29:51AM +0800, 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 ever
On Wed, Feb 19, 2014 at 11:10:41AM -0500, Austin S Hemmelgarn wrote:
> Currently, btrfs balance start fails when trying to convert metadata or
> system chunks to dup profile on filesystems with multiple devices. This
> requires that a conversion from a multi-device filesystem to a single
> device
Now that we can adjust the commit interval with a remount, we need
to wake up the transaction thread or else he will continue to sleep
until the previous transaction interval has elapsed before waking
up. So, if we go from a large commit interval to something smaller,
the transaction thread will n
On 2/19/14, 7:43 PM, Wang Shilong wrote:
> On 02/20/2014 09:39 AM, Eric Sandeen wrote:
>> On 2/19/14, 7:30 PM, Wang Shilong wrote:
...
>>> +/*
>>> + * if we pass a negative number to strtoull,
>>> + * it will return an unexpected number to us,
>>> + * so let's do the check ourselv
On Wed, Feb 19, 2014 at 07:17:51PM +0800, Wang Shilong wrote:
> +u64 btrfs_strtoull(char *str, int base)
> +{
> + u64 value;
> + char *ptr_parse_end = NULL;
> + char *ptr_str_end = str + strlen(str);
> +
> + value = strtoull(str, &ptr_parse_end, base);
> + if (ptr_parse_end != p
Hi list -
Can anybody tell me whether btrfs-raid10 reads and writes a stripe at a
time, like traditional raid10, or whether it reads and writes individual
redundant blocks like btrfs-raid1, but just locks particular disks as
mirror pairs, and/or locks the order in which mirror pairs should be
During restoring of image (-r using btrfs-image) we zero out RAID
profile in chunk type but forget to save BTRFS_BLOCK_GROUP_DUP if
present. This results in some false messages being printed by btrfsck.
$ ./mkfs.btrfs /dev/sdb2 -f
$ ./btrfs-image /dev/sdb2 btrfs_image_output
$ ./btrfs-image -r
@Kai Krakow: I accept your opinion and thank you for your answer.
However I have special reasons doing so. I could name you a few use cases.
For example I do not need to backup search indexes as they mess up over time,
so I simple recreate the cache in case of a new install.
I know most of the s
On 02/20/2014 07:25 PM, Sebastian Ochmann wrote:
Hello,
Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 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.
Did you ena
Hello,
I am noticing some weird behavior with btrfs device add. The command
does not return/finish although there is no disk activity in iotop. I
have compiled a gist [1] with the details, which I would gladly update,
if anyone knows what additional information I can provide.
kind regards,
Niklas
On Wed, Feb 5, 2014 at 3:17 PM, David Sterba wrote:
> The fs_path structure uses an inline buffer and falls back to a chain of
> allocations, but vmalloc is not necessary because PATH_MAX fits into
> PAGE_SIZE.
>
> The size of fs_path has been reduced to 256 bytes from PAGE_SIZE,
> usually 4k. Exp
Hello,
Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 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.
Did you enable nodatacow option? if nodatacow option is enabled
Wang Shilong posted on Thu, 20 Feb 2014 18:51:10 +0800 as excerpted:
> On 02/20/2014 06:31 PM, Duncan wrote:
>> Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 as
>> excerpted:
>>
>>> So my question is, why does scrub show a high (i.e. non-zero) value
>>> for no_csum? I never enabled n
Kai Krakow posted on Wed, 19 Feb 2014 21:20:23 +0100 as excerpted:
> Duncan had a nice example in this list how to migrate
> directories to subvolumes by using shallow copies: "mv dir dir.old &&
> btrfs sub create dir && cp -a -- reflink=always dir.old/. dir/. && rm
> -Rf dir.old".
FWIW, that wa
On 02/20/2014 06:31 PM, Duncan wrote:
Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 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.
Did you enable nodatacow option? if nodatacow option
Sebastian Ochmann posted on Wed, 19 Feb 2014 13:58:17 +0100 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.
I've no answer but have wondered that myself. So hopefully you get an
answer I can read t
If the log sync fails, there is something wrong in the log tree, we
should not continue to join the log transaction and log the metadata.
What we should do is to do a full commit.
This patch fixes this problem by setting ->last_trans_log_full_commit
to the current transaction id, it will tell the
The old code would start the log transaction even the log tree init
failed, it was unnecessary. Fix it.
Signed-off-by: Miao Xie
---
fs/btrfs/tree-log.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index
It is possible that many tasks sync the log tree at the same time, but
only one task can do the sync work, the others will wait for it. But those
wait tasks didn't get the result of the log sync, and returned 0 when they
ended the wait. It caused those tasks skipped the error handle, and the
seriou
We might commit the log sub-transaction which didn't contain the metadata we
logged. It was because we didn't record the log transid and just select
the current log sub-transaction to commit, but the right one might be
committed by the other task already. Actually, we needn't do anything
and it is
We may abort the wait earlier if ->last_trans_log_full_commit was set to
the current transaction id, at this case, we need commit the current
transaction instead of the log sub-transaction. But the current code
didn't tell the caller to do it (return 0, not -EAGAIN). Fix it.
Signed-off-by: Miao Xi
The log trans id is initialized to be 0 every time we create a log tree,
and the log tree need be re-created after a new transaction is started,
it means the log trans id is unlikely to be a huge number, so we can use
signed integer instead of unsigned long integer to save a bit space.
Signed-off-
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.c | 25 ++---
fs/btrfs/ctree.h | 39 +--
fs/btrfs/disk-io.c | 33 +++--
fs/btrfs/extent-tree.c | 6 +++---
fs/btrfs/file.c| 4 +++-
fs/btrfs/ino
Mutex unlock implies certain memory barriers to make sure all the memory
operation completes before the unlock, and the next mutex lock implies memory
barriers to make sure the all the memory happens after the lock. So it is
a full memory barrier(smp_mb), we needn't add memory barriers. Remove them
->last_trans_log_full_commit may be changed by the other tasks without lock,
so we need prevent the compiler from the optimize access just like
tmp = fs_info->last_trans_log_full_commit
if (tmp == ...)
...
if (tmp == ...)
...
In fa
On Thu, 2014-02-20 at 08:48 +, Mike Fleetwood wrote:
> On 20 February 2014 02:49, Gui Hecheng wrote:
> > When exec btrfs-debug-tree as non-root user, we get a segment fault.
> > Because the btrfs_scan_block_devices return a success 0 when we fail
> > to open a device. Now we just return the er
On 20 February 2014 02:49, Gui Hecheng wrote:
> When exec btrfs-debug-tree as non-root user, we get a segment fault.
> Because the btrfs_scan_block_devices return a success 0 when we fail
> to open a device. Now we just return the errno if this case happens.
>
> Signed-off-by: Gui Hecheng
> ---
>
43 matches
Mail list logo