On 20 February 2014 02:49, Gui Hecheng guihc.f...@cn.fujitsu.com 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:
-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 == ...)
...
do something
if (tmp == ...)
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-by: Miao Xie mi...@cn.fujitsu.com
---
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|
The old code would start the log transaction even the log tree init
failed, it was unnecessary. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/tree-log.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/fs/btrfs/tree-log.c
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
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
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
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
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
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 was someone
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 nodatasum or
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
On Wed, Feb 5, 2014 at 3:17 PM, David Sterba dste...@suse.cz 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,
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,
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
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
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
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 !=
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 ourselves firstly.
+
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
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
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
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 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
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 of
-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).
The
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 commands
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_info, and
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
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 remember seeing it
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 of a
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
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
On Tue, Feb 18, 2014 at 03:28:57PM -0500, J. Bruce Fields wrote:
From: J. Bruce Fields bfie...@redhat.com
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 bfie...@redhat.com
On Tue, Feb 18, 2014 at 03:28:58PM -0500, J. Bruce Fields wrote:
From: J. Bruce Fields bfie...@redhat.com
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
- 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
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
39 matches
Mail list logo
