ack);
this would cost +1 pointer for each function. But this would save from
situation like
r = init_a();
if (r)
init_b();
init_c();
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Goffredo-Baroncelli/btrfs-add-ioctl-BTRFS_IOC_DEV_PROPERTIES/20210223-062001
base: https://git.kernel.org/pub/scm/linux/
I resend it because I made a little mess with the quotation
On 2/23/21 6:59 PM, Goffredo Baroncelli wrote:
On 2/23/21 2:53 PM, David Sterba wrote:
On Mon, Feb 22, 2021 at 10:19:06PM +0100, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
This ioctl is a base for returning / setting
On 2/23/21 2:53 PM, David Sterba wrote:
On Mon, Feb 22, 2021 at 10:19:06PM +0100, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
This ioctl is a base for returning / setting information from / to the
fields of the btrfs_dev_item object.
Hi David,
Please don't add a new ioct
Hi Zygo,
if you are using the previous patches set, pay attention that there is a bug in
the previous iteration (V5 and V6) which could cause the crash of btrfs.
BR
G.Baroncelli
On 2/22/21 10:22 PM, Goffredo Baroncelli wrote:
Sorry, the subject is wrong, it should be [RFC][PATCH V7][PATCH 0
From: Goffredo Baroncelli
Handle the property allocation_hint of a btrfs device. Below
an example of use:
$ # set a new value
$ sudo btrfs property set /dev/vde allocation_hint DATA_ONLY
$ # get the current value
$ sudo btrfs property get /dev/vde allocation_hint
devid=4, path=/dev/vde
From: Goffredo Baroncelli
Update the header to add the BTRFS_IOC_DEV_PROPERTIES ioctl:
- add ioctl BTRFS_IOC_DEV_PROPERTIES define
- add struct btrfs_ioctl_dev_properties
- add the BTRFS_DEV_PROPERTY_ define
This ioctl is a base for returning / setting information from / to the
fields of the
From: Goffredo Baroncelli
This patches set is the userspace portion of the serie
"[PATCH V7] btrfs: allocation_hint mode".
Look this patches set for further information.
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2
Sorry, the subject is wrong, it should be [RFC][PATCH V7][PATCH 0/4] btrfs:
allocation_hint mode (seven instead six)
On 2/22/21 10:19 PM, Goffredo Baroncelli wrote:
Hi all,
This patches set was born after some discussion between me, Zygo and Josef.
Some details can be found in https
loop1.
TODO:
- more tests
- the tool which show the space available should consider the tagging (
the disks tagged by _METADATA_ONLY should be excluded from the data
availability)
Comments are welcome
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5
From: Goffredo Baroncelli
This ioctl is a base for returning / setting information from / to the
fields of the btrfs_dev_item object.
For now only the "type" field is returned / set.
Signed-off-by: Goffredo Baroncelli
---
fs/btrfs/ioctl.c
From: Goffredo Baroncelli
When this mode is enabled, the chunk allocation policy is modified as
follow.
Each disk may have a different tag:
- BTRFS_DEV_ALLOCATION_PREFERRED_METADATA
- BTRFS_DEV_ALLOCATION_METADATA_ONLY
- BTRFS_DEV_ALLOCATION_DATA_ONLY
- BTRFS_DEV_ALLOCATION_PREFERRED_DATA
From: Goffredo Baroncelli
Add the following flags to give an hint about which chunk should be
allocated in which a disk.
The following flags are created:
- BTRFS_DEV_ALLOCATION_PREFERRED_DATA
preferred data chunk, but metadata chunk allowed
- BTRFS_DEV_ALLOCATION_PREFERRED_METADATA
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
---
fs/btrfs/sysfs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 6eb1c50fa98c..9b2a18911de6 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -1418,11 +1418,22
On 2/1/21 10:28 PM, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
When this mode is enabled, the chunk allocation policy is modified as follow.
Each disk may have a different tag:
- BTRFS_DEV_ALLOCATION_PREFERRED_METADATA
- BTRFS_DEV_ALLOCATION_METADATA_ONLY
allocation_policy {
BTRFS_CHUNK_ALLOC_ZONED,
};
+/*
+ * If we have more than the required number of the devices for striping,
+ * chunk_layout let us know which device to use.
+ */
+enum btrfs_chunk_layout {
+ /* Use in the order of the size of the unallocated space on the device
*/
+ BTRFS_CHUNK_LAYOUT_SIZE,
+ BTRFS_NR_CHUNK_LAYOUT,
+};
+
/*
* Read policies for mirrored block group profiles, read picks the stripe
based
* on these policies.
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
On 2/10/21 5:04 PM, Josef Bacik wrote:
On 2/1/21 4:28 PM, Goffredo Baroncelli wrote:
Hi all,
the previous V5 serie was called "btrfs: preferred_metadata: preferred device
for metadata".
A few general points up front, first I'd highly recommend reading our patch
submis
On 2/10/21 5:09 PM, Josef Bacik wrote:
On 2/1/21 4:28 PM, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
[...]
+
+/* btrfs chunk allocation hints */
+#define BTRFS_DEV_ALLOCATION_MASK_BIT_COUNT 3
+#define BTRFS_DEV_ALLOCATION_MASK ((1ULL
On 2/10/21 5:14 PM, Josef Bacik wrote:
On 2/1/21 4:28 PM, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
Add allocation_hint mount option. This option accepts the following values:
- 0 (default): the chunks allocator ignores the disk hints
- 1: the chunks allocator
On 2/10/21 5:12 PM, Josef Bacik wrote:
On 2/1/21 4:28 PM, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
[...]
+ int hint;
+
+ static const char alloc_hint_map[BTRFS_DEV_ALLOCATION_MASK_COUNT] = {
+ [BTRFS_DEV_ALLOCATION_DATA_ONLY] = -1
On 2/10/21 5:08 PM, Josef Bacik wrote:
On 2/1/21 4:28 PM, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
This ioctl is a base for returning / setting information from / to the
fields of the btrfs_dev_item object.
For now only the "type" field is returned / set.
Sig
er because it's nodatacow or it sees that
these many extents are mostly contiguous and not worth defragmenting
(which would be good for keeping write amplification down).
So I don't know, maybe it's not wrong.
--
Chris Murphy
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
On 2/9/21 8:01 PM, Chris Murphy wrote:
On Tue, Feb 9, 2021 at 11:13 AM Goffredo Baroncelli wrote:
On 2/9/21 1:42 AM, Chris Murphy wrote:
Perhaps. Attach strace to journald before --rotate, and then --rotate
https://pastebin.com/UGihfCG9
I looked to this strace.
in line 115: it is called
5:1629541:
last,unknown_loc,delalloc,eof
/mnt/btrfs-raid1/home/ghigo/data.txt: 30 extents found
Start defrag with sync
End defrag
End sync
Filesystem type is: 9123683e
File size of /mnt/btrfs-raid1/home/ghigo/data.txt is 11046912 (2697 blocks of
4096 bytes)
ext: logical_offset:physical_offset: length: expected: flags:
0:0..2696: 163503187.. 163505883: 2697: last,eof
/mnt/btrfs-raid1/home/ghigo/data.txt: 1 extent found
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
ving, it looks like all the extents fall into
two localities and within each locality the extents aren't that far
apart - so my guess is that this file is also not meaningfully
fragmented, in practice. Surely the drive firmware will reorder the
reads to arrive at the least amount of seeks?
--
On 2/5/21 12:24 AM, Zygo Blaxell wrote:
On Mon, Feb 01, 2021 at 10:28:20PM +0100, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli
[...]
Hi Zygo
Well, I guess if you're going to keep putting the mount option in each
new patch version, then I'm going to keep saying "pl
boxes with you. Free, fast and secure Mail & Cloud:
https://www.eclipso.eu - Time to change!
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
From: Goffredo Baroncelli
When this mode is enabled, the chunk allocation policy is modified as follow.
Each disk may have a different tag:
- BTRFS_DEV_ALLOCATION_PREFERRED_METADATA
- BTRFS_DEV_ALLOCATION_METADATA_ONLY
- BTRFS_DEV_ALLOCATION_DATA_ONLY
- BTRFS_DEV_ALLOCATION_PREFERRED_DATA
From: Goffredo Baroncelli
Add allocation_hint mount option. This option accepts the following values:
- 0 (default): the chunks allocator ignores the disk hints
- 1:the chunks allocator considers the disk hints
Signed-off-by: Goffredo Baroncelli
---
fs/btrfs/ctree.h | 12
From: Goffredo Baroncelli
Handle the property allocation_hint of a btrfs device. Below
an example of use:
$ # set a new value
$ sudo btrfs property set /dev/vde allocation_hint DATA_ONLY
$ # get the current value
$ sudo btrfs property get /dev/vde allocation_hint
devid=4, path=/dev/vde
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
---
fs/btrfs/sysfs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 19b9fffa2c9c..594e8445fe21 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -1416,11 +1416,22
This patches set is the userspace portion of the serie
"[PATCH V6] btrfs: allocation_hint mode".
Look this patches set for further information.
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
From: Goffredo Baroncelli
This ioctl is a base for returning / setting information from / to the
fields of the btrfs_dev_item object.
For now only the "type" field is returned / set.
Signed-off-by: Goffredo Baroncelli
---
fs/btrfs/ioctl.c
re placed on the disk loop5/loop7 even if
#the most empty one are loop0 and loop1.
TODO:
- more tests
- the tool which show the space available should consider the tagging (
the disks tagged by _METADATA_ONLY should be excluded from the data
availability)
Comments are welcome
BR
G.Baroncelli
From: Goffredo Baroncelli
Update the header to add the BTRFS_IOC_DEV_PROPERTIES ioctl:
- add ioctl BTRFS_IOC_DEV_PROPERTIES define
- add struct btrfs_ioctl_dev_properties
- add the BTRFS_DEV_PROPERTY_ define
This ioctl is a base for returning / setting information from / to the
fields of the
From: Goffredo Baroncelli
Add the following flags to give an hint about which chunk should be
allocated in which a disk.
The following flags are created:
- BTRFS_DEV_ALLOCATION_PREFERRED_DATA
preferred data chunk, but metadata chunk allowed
- BTRFS_DEV_ALLOCATION_PREFERRED_METADATA
that the api is not so good.
Moreover, as explained also by you, the xattr are "exposed" to the risk
of be copied by a simple rsync -X (or cp --preserve=all ...)
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
On 1/21/21 7:54 PM, Zygo Blaxell wrote:
On Thu, Jan 21, 2021 at 07:16:05PM +0100, Goffredo Baroncelli wrote:
On 1/20/21 5:02 PM, Josef Bacik wrote:
On 1/17/21 1:54 PM, Goffredo Baroncelli wrote:
Hi all,
This is an RFC; I wrote this patch because I find the idea interesting
even though it
On 1/20/21 5:02 PM, Josef Bacik wrote:
On 1/17/21 1:54 PM, Goffredo Baroncelli wrote:
Hi all,
This is an RFC; I wrote this patch because I find the idea interesting
even though it adds more complication to the chunk allocator.
The basic idea is to store the metadata chunk in the fasters
From: Goffredo Baroncelli
When this mode is enabled, the chunk allocation policy is modified
giving a different precedence between the disks depending by the chunk type.
A disk may be marked with the preferred_metadata flag to have higher chance
to host metadata.
There are 4 modes
From: Goffredo Baroncelli
---
fs/btrfs/ioctl.c | 67 ++
fs/btrfs/volumes.c | 2 +-
fs/btrfs/volumes.h | 2 ++
include/uapi/linux/btrfs.h | 40 +++
4 files changed, 110 insertions(+), 1 deletion(-)
diff --git a
bit more complex, to avoid an interactive session
# mkfs.btrfs -m single -d single /dev/sdX
# mount /dev/sdX test/
# cd test
# time tar xzf ../image.tgz
# chroot .
# mount -t proc proc proc
# mount -t sysfs sys sys
# export DEBIAN_FRONTEND=noninteractive
# time apt-get -y --option=Dpkg::Options::=--force-confold \
--option=Dpkg::options::=--force-unsafe-io dist-upgrade
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
From: Goffredo Baroncelli
---
fs/btrfs/sysfs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index 19b9fffa2c9c..594e8445fe21 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -1416,11 +1416,22 @@ static ssize_t
From: Goffredo Baroncelli
Add preferred_metadata mount option. This option accept the following values:
- disabled (default): the disk preferred metadata flag is ignored
- soft:the disk preferred metadata flag is a suggestion
on which disk the system may
From: Goffredo Baroncelli
---
include/uapi/linux/btrfs_tree.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
index 58d7cff9afb1..701ad550d596 100644
--- a/include/uapi/linux/btrfs_tree.h
+++ b/include/uapi/linux
num_written = btrfs_buffered_write(iocb, from);
-------
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
image file with these 'errors'
cluttering up my file system and making backups of the host go
extremely slow. I'd like to get those blocks back so I can make a clean
copy of the image, and keep it around for reference in case I later
*do* discover that I need the contents of those blocks
ossible to increase
the likelihood of an inclusion. Eventually we can put further constraint after.
Anyway I am rebasing the patch to the latest kernel. Let me to check how complex
could be implement you algorithm (the two bits one).
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baron
On 1/8/21 6:30 PM, Goffredo Baroncelli wrote:
On 1/8/21 2:05 AM, Zygo Blaxell wrote:
On Thu, May 28, 2020 at 08:34:47PM +0200, Goffredo Baroncelli wrote:
[...]
I've been testing these patches for a while now. They enable an
interesting use case that can't otherwise be done safe
On 1/8/21 2:05 AM, Zygo Blaxell wrote:
On Thu, May 28, 2020 at 08:34:47PM +0200, Goffredo Baroncelli wrote:
[...]
I've been testing these patches for a while now. They enable an
interesting use case that can't otherwise be done safely, sanely or
cheaply with btrfs.
Thanks Zyg
On 12/21/20 9:27 PM, Remi Gauvin wrote:
On 2020-12-21 3:14 p.m., Goffredo Baroncelli wrote:
A subvolume can be moved everywhere with a simple 'mv' command.
No, they can not,, try this again with a *read only* snapshot
The topic was about why put the subvolumes/snapshots
ean the same thing in Btrfs,
the only difference being that "snapshot"-subvolume started its life as
being a full copy(-on-write) of some other subvolume.
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
2/
$ find sub2/
sub2/
sub2/sub1
sub2/sub1/sub12
sub2/sub1/sub11
This will not matter if your only subvolume is the filesystem root, but
if things were later be subdivided into other subvolumes, it will make
things much quicker and easier to be able to move the .my_snapshots
subvolume.
--
g
On 30/07/2019 16.48, Torstein Eide wrote:
> Hi
> Is there any news to implementing journal for raid5/6 writes?
>
I think that you should ask to ML. I am (was) occasional contributor than a
active btrfs developers.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baronc
On 18/03/2019 20.12, Stéphane Lesimple wrote:
> Le 2019-03-17 19:41, Goffredo Baroncelli a écrit :
>> On 17/03/2019 13.51, stephane_bt...@lesimple.fr wrote:
>> [...]
>>> - if (!ratio)
>>> - warning("RAID56 detected, not implemented")
lar) user should be warned about that: the
printed
info may be not correct.
[...]
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
og.
In case of unclean shutdown, it is already implemented a way to replay the log.
So it would be sufficient to track a scrub of these area as "log replay".
Of course I am talking as not a BTRFS developers, so the reality could be more
complex: e.g. I don't know how it would be easy to raise a scrub process on per
area basis.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
num_stripes = map->num_stripes;
>
> - preferred_mirror = first + current->pid % num_stripes;
> + preferred_mirror = first + guess_optimal(map, num_stripes,
> + current->pid % num_stripes);
>
> if (dev_replace_is_ongoing &&
> fs_info->dev_replace.cont_reading_from_srcdev_mode ==
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
On 31/10/2018 13.06, Daniel Kiper wrote:
[...]
>
> v11 pushed.
>
> Goffredo, thank you for doing the work.
Great ! Many thanks for your support !!
>
> Nick, you can go ahead and rebase yours patchset.
>
> Daniel
>
BR
G.Baroncelli
--
gpg @keyserver.linux.i
From: Goffredo Baroncelli
Move the code in charge to read the data from disk into a separate
function. This helps to separate the error handling logic (which depends on
the different raid profiles) from the read from disk logic.
Refactoring this code increases the general readability too.
This
From: Goffredo Baroncelli
The original code which handles the recovery of a RAID 6 disks array
assumes that all reads are multiple of 1 << GRUB_DISK_SECTOR_BITS and it
assumes that all the I/O is done via the struct grub_diskfilter_segment.
This is not true for the btrfs code. In order to
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
Signed-off-by: Daniel Kiper
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 73
1 file changed, 73 insertions(+)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index
From: Goffredo Baroncelli
The caller knows better if this error is fatal or not, i.e. another disk is
available or not.
This is a preparatory patch.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 10 --
1 file changed, 4 insertions(+), 6
From: Goffredo Baroncelli
A portion of the logging code is moved outside of internal for(;;). The part
that is left inside is the one which depends on the internal for(;;) index.
This is a preparatory patch. The next one will refactor the code inside
the for(;;) into an another function
Hi All,
the aim of this patches set is to provide support for a BTRFS raid5/6
filesystem in GRUB.
The first patch, implements the basic support for raid5/6. I.e this works when
all the disks are present.
The next 5 patches, are preparatory ones.
The 7th patch implements the raid5 recovery fo
From: Goffredo Baroncelli
Add support for recovery for a RAID 5 btrfs profile. In addition
it is added some code as preparatory work for RAID 6 recovery code.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 159
From: Goffredo Baroncelli
This helper is used in a few places to help the debugging. As
conservative approach the error is only logged.
This does not impact the error handling.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 24
From: Goffredo Baroncelli
Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
disks (up to two) are missing. This code use the md RAID 6 code already
present in grub.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 60
From: Goffredo Baroncelli
Currently read from missing device triggers rescan. However, it is never
recorded that the device is missing. So, each read of a missing device
triggers rescan again and again. This behavior causes a lot of unneeded
rescans leading to huge slowdowns.
This patch fixes
From: Goffredo Baroncelli
The caller knows better if this error is fatal or not, i.e. another disk is
available or not.
This is a preparatory patch.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 10 --
1 file changed, 4 insertions(+), 6
From: Goffredo Baroncelli
The original code which handles the recovery of a RAID 6 disks array
assumes that all reads are multiple of 1 << GRUB_DISK_SECTOR_BITS and it
assumes that all the I/O is done via the struct grub_diskfilter_segment.
This is not true for the btrfs code. In order to
From: Goffredo Baroncelli
Move the code in charge to read the data from disk into a separate
function. This helps to separate the error handling logic (which depends on
the different raid profiles) from the read from disk logic.
Refactoring this code increases the general readability too.
This
From: Goffredo Baroncelli
This helper is used in a few places to help the debugging. As
conservative approach the error is only logged.
This does not impact the error handling.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 24
From: Goffredo Baroncelli
Add support for recovery for a RAID 5 btrfs profile. In addition
it is added some code as preparatory work for RAID 6 recovery code.
Signed-off-by: Goffredo Baroncelli
---
grub-core/fs/btrfs.c | 161 +--
1 file changed, 156
'('
- patch 9: update the wording in the comment; s/raid6/RAID 6/ in
grub_dprintf()
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
From: Goffredo Baroncelli
Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
disks (up to two) are missing. This code use the md RAID 6 code already
present in grub.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 60
From: Goffredo Baroncelli
A portion of the logging code is moved outside of internal for(;;). The part
that is left inside is the one which depends on the internal for(;;) index.
This is a preparatory patch. The next one will refactor the code inside
the for(;;) into an another function
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
Signed-off-by: Daniel Kiper
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 73
1 file changed, 73 insertions(+)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index
From: Goffredo Baroncelli
Currently read from missing device triggers rescan. However, it is never
recorded that the device is missing. So, each read of a missing device
triggers rescan again and again. This behavior causes a lot of unneeded
rescans leading to huge slowdowns.
This patch fixes
From: Goffredo Baroncelli
The original code which handles the recovery of a RAID 6 disks array
assumes that all reads are multiple of 1 << GRUB_DISK_SECTOR_BITS and it
assumes that all the I/O is done via the struct grub_diskfilter_segment.
This is not true for the btrfs code. In order to
From: Goffredo Baroncelli
Move the code in charge to read the data from disk into a separate
function. This helps to separate the error handling logic (which depends on
the different raid profiles) from the read from disk logic.
Refactoring this code increases the general readability too.
This
From: Goffredo Baroncelli
Add support for recovery for a RAID 5 btrfs profile. In addition
it is added some code as preparatory work for RAID 6 recovery code.
Signed-off-by: Goffredo Baroncelli
---
grub-core/fs/btrfs.c | 162 +--
1 file changed, 157
From: Goffredo Baroncelli
Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
disks (up to two) are missing. This code use the md RAID 6 code already
present in grub.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 60
From: Goffredo Baroncelli
Currently read from missing device triggers rescan. However, it is never
recorded that the device is missing. So, each read of a missing device
triggers rescan again and again. This behavior causes a lot of unneeded
rescans leading to huge slowdowns.
This patch fixes
From: Goffredo Baroncelli
This helper is used in a few places to help the debugging. As
conservative approach the error is only logged.
This does not impact the error handling.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 24
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
Signed-off-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 73
1 file changed, 73 insertions(+)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index be195448d..933a57d3b 100644
From: Goffredo Baroncelli
The caller knows better if this error is fatal or not, i.e. another disk is
available or not.
This is a preparatory patch.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 10 --
1 file changed, 4 insertions(+), 6
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
From: Goffredo Baroncelli
A portion of the logging code is moved outside of internal for(;;). The part
that is left inside is the one which depends on the internal for(;;) index.
This is a preparatory patch. The next one will refactor the code inside
the for(;;) into an another function
From: Goffredo Baroncelli
The original code which handles the recovery of a RAID 6 disks array
assumes that all reads are multiple of 1 << GRUB_DISK_SECTOR_BITS and it
assumes that all the I/O is done via the struct grub_diskfilter_segment.
This is not true for the btrfs code. In order to
From: Goffredo Baroncelli
Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
disks (up to two) are missing. This code use the md RAID 6 code already
present in grub.
Signed-off-by: Goffredo Baroncelli
---
grub-core/fs/btrfs.c | 63
From: Goffredo Baroncelli
Move the code in charge to read the data from disk into a separate
function. This helps to separate the error handling logic (which depends on
the different raid profiles) from the read from disk logic.
Refactoring this code increases the general readability too.
This
From: Goffredo Baroncelli
The caller knows better if this error is fatal or not, i.e. another disk is
available or not.
This is a preparatory patch.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 10 --
1 file changed, 4 insertions(+), 6
From: Goffredo Baroncelli
A portion of the logging code is moved outside of internal for(;;). The part
that is left inside is the one which depends on the internal for(;;) index.
This is a preparatory patch. The next one will refactor the code inside
the for(;;) into an another function
From: Goffredo Baroncelli
Change the behavior of find_device(): before the patch, a read of a missed
device may trigger a rescan. However, it is never recorded that a device
is missed, so each single read of a missed device may triggers a rescan.
It is the caller who decides if a rescan is
From: Goffredo Baroncelli
Add support for recovery for a RAID 5 btrfs profile. In addition
it is added some code as preparatory work for RAID 6 recovery code.
Signed-off-by: Goffredo Baroncelli
---
grub-core/fs/btrfs.c | 160 +--
1 file changed, 155
From: Goffredo Baroncelli
This helper is used in a few places to help the debugging. As
conservative approach the error is only logged.
This does not impact the error handling.
Signed-off-by: Goffredo Baroncelli
Reviewed-by: Daniel Kiper
---
grub-core/fs/btrfs.c | 24
ceived an update to the comment
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
From: Goffredo Baroncelli
Signed-off-by: Goffredo Baroncelli
---
grub-core/fs/btrfs.c | 74
1 file changed, 74 insertions(+)
diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
index be195448d..9bc6d399d 100644
--- a/grub-core/fs/btrfs.c
+++ b
On 25/09/2018 17.31, Daniel Kiper wrote:
> On Wed, Sep 19, 2018 at 08:40:32PM +0200, Goffredo Baroncelli wrote:
>> From: Goffredo Baroncelli
>>
>> Signed-off-by: Goffredo Baroncelli
>> ---
>> grub-core/fs/btrfs.c | 66 ++
1 - 100 of 1175 matches
Mail list logo
