On Mon, Dec 15, 2014 at 10:36 PM, Satoru Takeuchi
wrote:
> Is "btrfs property get " (and some one liner) insufficient for
> your purpose?
I was not previously aware of btrfs property, thanks for mentioning
this. man btrfs does not list the property command; although man btrfs
property does expla
(2014/12/11 17:31), Dongsheng Yang wrote:
> We just need the type of a chunk to calculate the number of parity stripes,
> but we have to pass a structure of lookup_map to it. This will prevent some
> callers to use it where there is no a convenient lookup_map to be passed.
>
> This patch replace t
Hi Ali,
(2014/12/16 11:01), Ali AlipourR wrote:
Hi
I think it will be to add option to "btrfs subvolume list" command to
also show the property of sub volumes (ro, compression,...)? do this
is possible?
Of course it's possible by writing some code :-D
Is "btrfs property get " (and some one l
(2014/12/16 5:02), Goffredo Baroncelli wrote:
> Add -v -q switches to mkfs.btrfs, to control the verbosity of mkfs.btrfs.
>
> Signed-off-by: Goffredo Baroncelli
Although this patch provides the interface of two new switches,
it doesn't work at all only by this patch. I consider providing
switch
On 12/15/2014 07:30 PM, Robert White wrote:
The above would be ideal. But POSIX says "no". f_blocks is defined (only
Correction the linux kernel says "total data blocks", POSIX says "total
blocks" -- it was a mental typo... 8-)
in the comments) as "total data blocks in the filesystem" and /bin/
On 12/15/2014 05:58 PM, Duncan wrote:
* Please s/disk/device/, here and possibly elsewhere. I know I'm not the
only one who is trying to make the switch in my own usage, as it looks a
bit foolish (and/or marks the user as an old fogey who's likely to start
lecturing about how a GiB isn't "small"
On 12/15/2014 01:36 AM, Robert White wrote:
So we don't just hand-wave over statfs(). We include the
dev_item.bytes_excluded in the superblock and we decide once-and-for-all
(with any geometry creation, or completed conversion) how many bytes
just _can't_ be reached but only once we _know_ they c
(2014/12/16 5:02), Goffredo Baroncelli wrote:
> This patch print the summary of the filesystem after the creation.
> The main fileds printed are:
> - devices list with their uuid, devid, path and size
> - raid profile (dup,single,raid0...)
> - leafsize/nodesize/sectorsize
> - filesystem features (r
Hi Goffredo,
(2014/12/16 5:02), Goffredo Baroncelli wrote:
>
>
> Hi All,
>
> enclosed a patches set to improve the output of mkfs.btrfs command.
The idea looks nice to me. I have some comments about
new output.
Thanks,
Satoru
>
> Currently I find the output of mkfs.btrfs command quite confu
Hi
I think it will be to add option to "btrfs subvolume list" command to
also show the property of sub volumes (ro, compression,...)? do this
is possible?
Thanks,
Ali
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mo
(2014/12/16 1:04), Filipe Manana wrote:
> If we are using skinny metadata, the block's tree level is in the offset
> of the key and not in a btrfs_tree_block_info structure following the
> extent item (it doesn't exist). Therefore fix it.
Yes, this key type is introduced by commit 3173a18.
fs/btr
Goffredo Baroncelli posted on Mon, 15 Dec 2014 21:02:59 +0100 as
excerpted:
> + printf(" Total disks size: %10s\n",
> + pretty_size(total_block_count));
I really like this patch series. Makes mkfs.btrfs much nicer to use. =:^)
I'm not a dev and won't att
Original Message
Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image +
corrupt script fsck test case.
From: David Sterba
To: Filipe David Manana
Date: 2014年12月16日 02:19
On Mon, Dec 15, 2014 at 10:13:45AM +, Filipe David Manana wrote:
So another thing I wo
Original Message
Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image +
corrupt script fsck test case.
From: Filipe David Manana
To: Qu Wenruo
Date: 2014年12月15日 17:43
On Mon, Dec 15, 2014 at 9:40 AM, Qu Wenruo wrote:
Original Message
Subject
Original Message
Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image +
corrupt script fsck test case.
From: David Sterba
To: Filipe David Manana
Date: 2014年12月16日 01:35
On Mon, Dec 15, 2014 at 09:36:51AM +, Filipe David Manana wrote:
So another thing I wo
On 2014-12-15 21:07, Josef Bacik wrote:
On 12/12/2014 09:37 AM, Tomasz Chmielewski wrote:
FYI, still seeing this with 3.18 (scrub passes fine on this
filesystem).
# time btrfs balance start /mnt/lxc2
Segmentation fault
real322m32.153s
user0m0.000s
sys 16m0.930s
Sorry Tomasz, y
On 12/12/2014 09:37 AM, Tomasz Chmielewski wrote:
FYI, still seeing this with 3.18 (scrub passes fine on this filesystem).
# time btrfs balance start /mnt/lxc2
Segmentation fault
real322m32.153s
user0m0.000s
sys 16m0.930s
Sorry Tomasz, you are now at the top of the list. I assu
Add -v and -o switches to the mkfs.btrfs man page.
Signed-off-by: Goffredo Baroncelli
---
Documentation/mkfs.btrfs.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/mkfs.btrfs.txt b/Documentation/mkfs.btrfs.txt
index ba7e42b..8ecb1a6 100644
--- a/Documentation/mkfs.b
This patch print the summary of the filesystem after the creation.
The main fileds printed are:
- devices list with their uuid, devid, path and size
- raid profile (dup,single,raid0...)
- leafsize/nodesize/sectorsize
- filesystem features (raid56, extref, mixed-bg)
If the '-v' switched is passed,
The function make_btrfs() has as argument the fsid of the filesystem.
If this fsid is empty or null make_btrfs() generates a new fsid. However
If the buffer is valid (but the string is empty) the generated fsid is
copied back to the caller.
Signed-off-by: Goffredo Baroncelli
---
utils.c | 7
Add verbose option to btrfs_add_to_fsid() in order to avoid to print
the information to console when not needed.
The same information is print in the summary of the mkfs.btrfs command.
Signed-off-by: Goffredo Baroncelli
---
utils.c | 7 ---
utils.h | 2 +-
2 files changed, 5 insertions(+), 4
When creating a new btrfs_device, copy the path to track it.
This path is then used by mkfs.btrfs to list all devices.
Signed-off-by: Goffredo Baroncelli
---
utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/utils.c b/utils.c
index dcb4f74..3f50e4d 100644
--- a/utils.c
+++ b/utils.c
@@
Move the group_profile_str() function from cmds-filesystem.c to utils.c
to be re-used from other modules (in this case from mkfs.c)
Signed-off-by: Goffredo Baroncelli
---
cmds-filesystem.c | 22 --
utils.c | 22 ++
utils.h | 2 ++
3 fi
Hi All,
enclosed a patches set to improve the output of mkfs.btrfs command.
Currently I find the output of mkfs.btrfs command quite confusing:
# mkfs.btrfs -f -M -d raid5 -m raid5 /dev/vd[b-k]
Btrfs v3.17
See http://btrfs.wiki.kernel.org for more information.
Turning ON incompat feature 'mi
Add -v -q switches to mkfs.btrfs, to control the verbosity of mkfs.btrfs.
Signed-off-by: Goffredo Baroncelli
---
mkfs.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/mkfs.c b/mkfs.c
index e10e62d..26f8041 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -288,8 +288,10
On Mon, Dec 01, 2014 at 03:23:03PM -0800, Alex Elsayed wrote:
> > I have not seen any evidence that combining hashes like that actually
> > reduces the chances of collision, but if we assume it does, then
> > again, the non-crypto hashes would be faster. For example, 128-bit
> > Spooky2 combined wi
On Mon, Dec 15, 2014 at 10:13:45AM +, Filipe David Manana wrote:
> >
> > So another thing I would like to see is doing a more comprehensive
> > verification that the repair code worked as expected. Currently we
> > only check that a readonly fsck, after running fsck --repair, returns
> > 0.
> >
On Mon, Dec 15, 2014 at 09:36:51AM +, Filipe David Manana wrote:
> So another thing I would like to see is doing a more comprehensive
> verification that the repair code worked as expected. Currently we
> only check that a readonly fsck, after running fsck --repair, returns
> 0.
>
> For the im
If we are using skinny metadata, the block's tree level is in the offset
of the key and not in a btrfs_tree_block_info structure following the
extent item (it doesn't exist). Therefore fix it.
Besides returning the correct level in the tree, this also prevents reading
past the leaf's end in the ca
On 2014-12-13 21:59, Ali AlipourR wrote:
Hi,
1- Do setting compression flag per subvolume is implemented?
(I did read on wiki that it is not implemented, but I can set it via
"btrfs property")
AFAIK, it's the compression related mount options that don't work
per-subvolume. Using chattr +c or
On Mon, Dec 15, 2014 at 9:36 AM, Filipe David Manana wrote:
> On Mon, Dec 15, 2014 at 3:54 AM, Qu Wenruo wrote:
>> Although btrfsck test case support pure image dump(tar.xz), it is still
>> too large for some images, e.g, a small 64M image with about 3 levels
>> (level 0~2) metadata will produce
On Mon, Dec 15, 2014 at 9:40 AM, Qu Wenruo wrote:
>
> Original Message
> Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image + corrupt
> script fsck test case.
> From: Filipe David Manana
> To: Qu Wenruo
> Date: 2014年12月15日 17:00
>>
>> On Mon, Dec 15, 2014 at 3:54
Original Message
Subject: Re: [PATCH 1/2] btrfs-progs: Add support for btrfs-image +
corrupt script fsck test case.
From: Filipe David Manana
To: Qu Wenruo
Date: 2014年12月15日 17:00
On Mon, Dec 15, 2014 at 3:54 AM, Qu Wenruo wrote:
Although btrfsck test case support pure im
On 12/15/2014 12:26 AM, Dongsheng Yang wrote:
On 12/15/2014 03:49 PM, Robert White wrote:
On 12/14/2014 10:06 PM, Robert White wrote:
On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
Anyone have some suggestion about it?
(... strong advocacy for raw numbers...)
Hi Robert, thanx for your so det
On Mon, Dec 15, 2014 at 3:54 AM, Qu Wenruo wrote:
> Although btrfsck test case support pure image dump(tar.xz), it is still
> too large for some images, e.g, a small 64M image with about 3 levels
> (level 0~2) metadata will produce about 2.6M after xz zip, which is too
> large for a single binary
On Mon, Dec 15, 2014 at 3:54 AM, Qu Wenruo wrote:
> Although btrfsck test case support pure image dump(tar.xz), it is still
> too large for some images, e.g, a small 64M image with about 3 levels
> (level 0~2) metadata will produce about 2.6M after xz zip, which is too
> large for a single binary
On 12/14/2014 11:41 PM, Nick Dimov wrote:
Hi, thanks for the answer, I will answer between the lines.
On 15.12.2014 08:45, Robert White wrote:
On 12/14/2014 08:50 PM, Nick Dimov wrote:
Hello everyone!
First, thanks for amazing work on btrfs filesystem!
Now the problem:
I use a ssd as my syst
On 12/15/2014 03:49 PM, Robert White wrote:
On 12/14/2014 10:06 PM, Robert White wrote:
On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
Anyone have some suggestion about it?
(... strong advocacy for raw numbers...)
Hi Robert, thanx for your so detailed reply.
You are proposing to report the r
38 matches
Mail list logo
