y to false before deleting it
btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "uns
d. It is
the data wrong.
BR
G.Baroncelli
>
> [1],
> https://patchwork.kernel.org/patch/9835505/
> Btrfs: report errors when checksum is not found
>
> Thanks,
>
> -liubo
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6
re useful.
BR
G.Baroncelli
>
> --
>
> With Best Regards, Marat Khalili
>
> -- 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://vger.kernel.org/majordomo-info.ht
On 09/15/2017 07:01 PM, Andrei Borzenkov wrote:
> 15.09.2017 08:50, Goffredo Baroncelli пишет:
>> On 09/15/2017 05:55 AM, Andrei Borzenkov wrote:
>>> 15.09.2017 01:00, Goffredo Baroncelli пишет:
>>>>
>>>> 2) The second bug, is a more severe bug. If during
On 09/15/2017 10:26 AM, Hugo Mills wrote:
> On Fri, Sep 15, 2017 at 08:04:35AM +0200, Goffredo Baroncelli wrote:
>> On 09/15/2017 12:18 AM, Hugo Mills wrote:
>>>As far as I know, both of these are basically known issues, with no
>>> good solution, other than no
(argc < 2) {
>> fprintf(stderr, "usage: %s \n", argv[0]);
>> exit(100);
>> }
>>
>>
>> buffer = mmap(NULL, FILESIZE,
>> PROT_READ|PROT_WRITE,
>> MAP_SHARE
On 09/15/2017 05:55 AM, Andrei Borzenkov wrote:
> 15.09.2017 01:00, Goffredo Baroncelli пишет:
>>
>> 2) The second bug, is a more severe bug. If during a writing of a buffer
>> with O_DIRECT, the buffer is updated at the same time by a second process,
>> th
derr, "read_thread pid = %d\n", child);
child = fork();
assert(child >= 0);
if (child == 0)
update_thread();
fprintf(stderr, "update_thread pid = %d\n", child);
for(;;)
sleep(100*100*100);
ux/zfs/issues/224
>
> --
>
> With Best Regards,
> Marat Khalili
> --
> 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://vger.kernel.org/majordomo-
are in more places, so removing these checks is a
quite intrusive change...
> at
> the beginning because I don't know what's the resulting size going to
> be. In this case, something like
>
> $ mkfs.btrfs --rootdir dir/ --minimize image
BR
G.Baroncelli
--
gpg @keyserver.linux.it
t;
> BTW, what's the output of dump-super here?
Further tests seems to highlight that it was a my setup problem. Before I build
mkfs.btrfs cross-compiling from an amd64, and I got the error; retrying on the
native environment I was unable to reproduce the problem.
So please ignore the previo
On 09/06/2017 08:02 PM, Austin S. Hemmelgarn wrote:
> On 2017-09-06 13:48, Goffredo Baroncelli wrote:
>> On 09/06/2017 07:16 PM, Austin S. Hemmelgarn wrote:
[...]
>>>> Sorry but I don't understand. If you reach the step a3; you have:
>>>> - the final disk, and an e
On 09/06/2017 07:16 PM, Austin S. Hemmelgarn wrote:
> On 2017-09-06 12:43, Goffredo Baroncelli wrote:
>> On 09/06/2017 01:31 PM, Austin S. Hemmelgarn wrote:
>>> On 2017-09-05 15:05, Goffredo Baroncelli wrote:
>>>> On 09/05/2017 10:19 AM, Qu Wenruo wrote:
>>
On 09/06/2017 01:31 PM, Austin S. Hemmelgarn wrote:
> On 2017-09-05 15:05, Goffredo Baroncelli wrote:
>> On 09/05/2017 10:19 AM, Qu Wenruo wrote:
>>>
>>>
>>> On 2017年09月05日 02:08, David Sterba wrote:
>>>> On Mon, Sep 04, 2017 at 03:41:05PM +0
gt;> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> 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://vger.kernel.org/majordomo
On 2017-08-31 20:49, Austin S. Hemmelgarn wrote:
> On 2017-08-31 13:27, Goffredo Baroncelli wrote:
>> Hi All,
>>
>>
>> I found a bug in mkfs.btrfs, when it is used the option '-r'. It
>> seems that it is not visible the full disk.
>>
>> $ uname -a
fully used. So I suppose
that it is a kernel problem (IIRC the kernel should "complete" the mkfs at the
first mount). Any idea ?
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe
if (ret)
>> + goto fail;
>> +
>> + btrfs_set_inode_size(leaf, inode_item, len * 2 +
>> + btrfs_inode_size(leaf, inode_item));
>> + btrfs_mark_buffer_dirty(leaf);
>> + btrfs_release_path();
[...]
If possible I would like to ask another
erate only
confusion.
As my first option, I am to have only mktable in the git with BUILD_CC/CFLAGS.
As second choice, we could remove mktable and put a comment that the tables are
the kernel ones.
BTW, I suggest to put a comment in table.c to change mktable in case of update
of the table. Otherwi
ithout a RMW cycle...
BR
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordo
On 08/19/2017 12:19 AM, Goffredo Baroncelli wrote:
>> We have no way of making sure nobody
>> touches the page while we're writing it out, so after we calculate the
>> checksum
>> any changes to the page are going to cause a checksum mismatch. O_DIRECT are
>> user s
On 08/18/2017 07:43 PM, Josef Bacik wrote:
> On Fri, Aug 18, 2017 at 06:23:18PM +0200, Goffredo Baroncelli wrote:
>> On 08/18/2017 01:39 AM, Josef Bacik wrote:
>> [...]
>>> This is happening because the app (the guest OS in this case, we saw this a
>>> lot
>
majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord..
On 08/18/2017 09:12 AM, Nikolay Borisov wrote:
>
>
> On 18.08.2017 10:09, Goffredo Baroncelli wrote:
>> On 08/18/2017 08:34 AM, Nikolay Borisov wrote:
[...]
>>> It would be awesome if you manage to introduce xfstests for this case
>>
>> I am not sure if thi
On 08/18/2017 08:34 AM, Nikolay Borisov wrote:
>
>
> On 17.08.2017 23:59, Goffredo Baroncelli wrote:
>> Hi,
>>
>> On 08/17/2017 08:43 PM, Chris Murphy wrote:
>>> # btrfs sub create test1
>>> Create subvolume './test1'
>>> # btrfs su
From: Goffredo Baroncelli <kreij...@inwind.it>
When ino = BTRFS_EMPTY_SUBVOL_DIR_OBJECTID, the item is not referred
to any file-tree. So lookup_path_rootid() doesn't return any sensate
value.
Signed-off-by: Goffredo Baroncelli <kreij...@inwind.it>
---
cmds-
last items, the error is returned
to the caller
2) in the function du_add_file() it doesn't make sense to call
lookup_path_rootid() when the inode is BTRFS_EMPTY_SUBVOL_DIR_OBJECTID: in this
case the function doesn't return a valid value.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baron
From: Goffredo Baroncelli <kreij...@inwind.it>
In du_walk_dir(), when du_add_file() returns an error it is
usually ignored. However if the error is returned querying
the last item, the error is returned to the caller.
Signed-off-by: Goffredo Baroncelli <kreij...@inwind.it>
---
cmds
0.00B 0.00B test1.snap
The error disappear !
Patches will follow shortly
>
> # uname -r
> 4.13.0-0.rc4.git1.1.fc27.x86_64
> # rpm -q btrfs-progs
> btrfs-progs-4.12-1.fc27.x86_64
>
>
>
> Chris Murphy
>
--
gpg @keyserver.linux.it: Goffredo Baronc
strace btrfs fi du -s /mnt/red/\@backup/
this shouldn't contain sensible information
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linu
On 08/14/2017 09:08 PM, Chris Murphy wrote:
> On Mon, Aug 14, 2017 at 8:23 AM, Goffredo Baroncelli <kreij...@inwind.it>
> wrote:
>
>> Form a theoretical point of view, if you have a "PURE" COW file-system, you
>> don't need a journal. Unfortunately a RAID5/6
On 08/14/2017 09:28 PM, Chris Murphy wrote:
> On Mon, Aug 14, 2017 at 8:12 AM, Goffredo Baroncelli <kreij...@inwind.it>
> wrote:
>> On 08/13/2017 08:45 PM, Chris Murphy wrote:
>>> [2]
>>> Is Btrfs subject to the write hole problem manifesting on disk? I'm
>&
nes is like 7. I don't see any benefit in what you
> propose and hopefully explained my viewpoint enough so I don't have to
> continue.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
>
theoretical point of view, if you have a "PURE" COW file-system, you
don't need a journal. Unfortunately a RAID5/6 stripe update is a RMW cycle, so
you need a journal to keep it in sync. The same is true for the NOCOW file (and
their checksums)
>
> Thanks,
> Qu
--
gpg @keyser
n 1) and 2) happen at the same
time (which is not impossible: i.e. if a disk die, it is not infrequent that
the user shutdown the machine without waiting a clean shutdown).
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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://vger.kernel.org/majordomo-info.html
also to solving also the issue related to the
infamous RAID5/6 hole: logging which block are updated, in case of transaction
aborted you can check the parity which have to be rebuild.
>
>Basically, nodatacow bypasses the very mechanisms that are meant to
> provide consistency in the filesyst
On 2017-08-03 19:23, Austin S. Hemmelgarn wrote:
> On 2017-08-03 12:37, Goffredo Baroncelli wrote:
>> On 2017-08-03 13:39, Austin S. Hemmelgarn wrote:
[...]
>>> Also, as I said below, _THIS WORKS ON ZFS_. That immediately means that a
>>> CoW filesystem _does not
On 2017-08-03 13:39, Austin S. Hemmelgarn wrote:
> On 2017-08-02 17:05, Goffredo Baroncelli wrote:
>> On 2017-08-02 21:10, Austin S. Hemmelgarn wrote:
>>> On 2017-08-02 13:52, Goffredo Baroncelli wrote:
>>>> Hi,
>>>>
>> [...]
>>
>>>&g
On 2017-08-03 13:44, Marat Khalili wrote:
> On 02/08/17 20:52, Goffredo Baroncelli wrote:
>> consider the following scenario:
>>
>> a) create a 2GB file
>> b) fallocate -o 1GB -l 2GB
>> c) write from 1GB to 3GB
>>
>> after b), the expectation is that c)
can detect
>> errors but repair thru raid5 may not recover the correct data.
>
> But nodatacow doesn't have checksum...
True, but Liu is correct stating that a write "nocow" is not protected by a
transaction.
The funny part, is that in case of raid5 we need to duplicate t
On 2017-08-02 21:10, Austin S. Hemmelgarn wrote:
> On 2017-08-02 13:52, Goffredo Baroncelli wrote:
>> Hi,
>>
[...]
>> consider the following scenario:
>>
>> a) create a 2GB file
>> b) fallocate -o 1GB -l 2GB
>> c) write from 1GB to 3GB
>>
>&g
Hi Liu,
thanks for your reply, below my comments
On 2017-08-02 19:57, Liu Bo wrote:
> On Wed, Aug 02, 2017 at 12:14:27AM +0200, Goffredo Baroncelli wrote:
>> On 2017-08-01 19:24, Liu Bo wrote:
>>> On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote:
>>>
ze
-- result: fail: the expansion fails
# fallocate -l $((1024*1024*100*15)) file.bin
# fallocate -l $((1024*1024*100*40)) file.bin
fallocate: fallocate failed: No space left on device
# ls -lh file.bin
-rw-r--r-- 1 root root 1.5G Aug 2 19:09 file.bin
--
gpg @keyserver.linux.it: Goffredo Baroncel
.
The data checksum are sufficient to detect if wrong data is returned. The
checksum parity is not needed. In any case both can't avoid the problem.
> Cheers,
> Chris.
>
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B
On 2017-08-01 19:24, Liu Bo wrote:
> On Tue, Aug 01, 2017 at 07:42:14PM +0200, Goffredo Baroncelli wrote:
>> Hi Liu,
>>
>> On 2017-08-01 18:14, Liu Bo wrote:
>>> This aims to fix write hole issue on btrfs raid5/6 setup by adding a
>>> separate disk as a j
t; fs/btrfs/volumes.h |7 +-
> include/uapi/linux/btrfs.h | 3 +
> include/uapi/linux/btrfs_tree.h |4 +
> 10 files changed, 1487 insertions(+), 176 deletions(-)
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 1
appear
you are not in position to recompute valid data in disk1 using only data2 and
parity
> No need to use parity at all.
>
> So that's why I think the hole write is not an urgent case to handle right
> now.
>
> Thanks,
> Qu
--
gpg @keyserver.linux.it: Goffredo Baro
ity is not data.
>
> Parity strip is differentiated from data strip, and by itself parity
> is meaningless. But parity plus n-1 data strips is an encoded form of
> the missing data strip, and is therefore an encoded copy of the data.
> We kinda have to treat the parity as fractional
ecksum to the parity should not solve any issue.
A possible "mitigation", is to track in a "intent log" all the not "full stripe
writes" during a transaction. If a power failure aborts a transaction, in the
next mount a scrub process is started to correct the pari
On 2017-06-07 20:04, Adam Borowski wrote:
> On Wed, Jun 07, 2017 at 07:01:21PM +0200, Goffredo Baroncelli wrote:
>> On 2017-06-07 17:58, Chris Murphy wrote:
>>> 3. My take on this would have been to use btrfs restore and go after
>>> the file path if I absolutely
> +e = errno;
>> +if (ret < 0) {
>> +fprintf(stderr, "ret %d error '%s'\n", ret,
>> +strerror(e));
>
> Please take a look how the error messages are constructed when the tree
> search ioctl fails, there are enough examples i
subscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B8
t; + * keys encountered.
Even this is correct, I still find a bit complicate to fully understand the
meaning.
I would prefer to replace "not used" with "not usable"... But as stated above I
am not a native English people :-)
BR
G.Baroncelli
--
gpg @keyserver.linux.
On 2017-05-29 02:21, Qu Wenruo wrote:
>
>
> At 05/27/2017 02:37 AM, Goffredo Baroncelli wrote:
>> Hi Qu,
>>
>> On 2017-05-25 08:21, Qu Wenruo wrote:
>>
>>> And since kernel scrub won't account P/Q corruption, it makes us quite
>>> hard to dete
wrong 'P' parity; am I missing something ?
BR
G.Baroncelli
[...]
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a m
. In
this BTRFS is not worse (nor better) than its competitor (xfs/ext3,4). I am
inclined to think that a warning for the write hole is a bit excessive.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscri
ncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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://vger.kernel.org/majordomo-info.html
helper" thread (
https://marc.info/?l=linux-btrfs=141736989508243=2 )
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a messa
On 2017-04-28 19:41, Chris Murphy wrote:
> On Fri, Apr 28, 2017 at 11:05 AM, Goffredo Baroncelli
> <kreij...@inwind.it> wrote:
>
>> In the past I faced the same problems; I collected some data here
>> http://kreijack.blogspot.it/2014/06/btrfs-and-systemd-jou
ster than journalctl (on a rotational media). Unfortunately I don't
have any data to support this.
However if someone is interested I can share more details.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
On 2017-04-26 02:13, Qu Wenruo wrote:
>
>
> At 04/26/2017 01:58 AM, Goffredo Baroncelli wrote:
>> I Qu,
>>
>> I tested these two patches on top of 4.10.12; however when I
>> corrupt disk1, It seems that BTRFS is still unable to rebuild
>> parity.
>&g
D2/P, and P's recovery code is just reading out full stripe, then we
> can cause unrecoverable error.
>
> This patch will use previously introduced lock_full_stripe() and
> unlock_full_stripe() to protect the whole scrub_handle_errored_block()
> function for RAID56 recovery.
&
from creating a
raid5/6 filesystem, and after some time prevent the kernel to mount this kind
of filesystem at all).
I hope that these issues will be addressed and BTRFS will gain a good raid5/6
support. But otherwise I think that it is better to deprecate it than support a
badly implementation.
s/ctree.h | 2 -
> fs/btrfs/disk-io.c | 87 ++
> fs/btrfs/disk-io.h | 2 -
> fs/btrfs/super.c | 5 +-
> fs/btrfs/volumes.c | 156
> -
> fs/btrfs/volumes.h | 37 +
> 6 files changed,
corruption). IIRC this use the same scrub code.
>
> Cheers.
> Lakshmipathi.G
> --
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-b
find an answer ?
>
> Thanks
> -
> Ilan Schwarts
>
>
>
>
> --
>
>
> -
> Ilan Schwarts
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "uns
and fix it, but first I have to ask:
>> - Which number is wrong?
>> The one returned by stat() or the one in mountinfo?
>
> The one in mountinfo, but then that means that the user only sees the
> anonymous devices in mount(8), which isn't what we want either.
>
> I'm afraid
On 2017-02-14 21:09, Lakshmipathi.G wrote:
> On Mon, Feb 06, 2017 at 09:40:47PM +0100, Goffredo Baroncelli wrote:
>>
>> IIRC, the parity is spread across the disk stripes of the chunk.
>>
>> So first you have to find the logical-offset [LO] where the the file begin
is wrong?
>> The one returned by stat() or the one in mountinfo?
>
> The one in mountinfo, but then that means that the user only sees the
> anonymous devices in mount(8), which isn't what we want either.
>
> I'm afraid the correct fix is very involved and requires non-tri
le point in time
> snapshots is a wrong assumption with possibly horrible side effects one
> wouldn't expect.
I don't understand what are you saying.
Until now, my understanding was that "all the writings which were passed to
btrfs before the snapshot time are in the snapshot. The
PATCH][V2] Add two new commands: 'btrfs insp physical-find' and
'btrfs insp physical-dump'
> Cheers.
> Lakshmipathi.G
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo i
ub: Introduce function to scrub one data stripe
>>> btrfs-progs: scrub: Introduce function to verify parities
>>> btrfs-progs: extent-tree: Introduce function to check if there is any
>>> extent in given range.
>>> btrfs-progs: scrub: Introduce funct
lumes.c | 283 ++++++
> volumes.h | 49 ++
> 16 files changed, 2103 insertions(+), 185 deletions(-)
> create mode 100644 csum.c
> create mode 100644 kernel-lib/mktables.c
> create mode 100644 kernel-lib/raid56.c
> crea
e past this was discussed, although I am not able to find any
reference...
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
MW because the erase
sector are bigger than the disk sector (4k ?).
>
> Thanks,
> Qu
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux
On 2016-11-28 01:40, Qu Wenruo wrote:
>
> At 11/27/2016 07:16 AM, Goffredo Baroncelli wrote:
>> On 2016-11-26 19:54, Zygo Blaxell wrote:
>>> On Sat, Nov 26, 2016 at 02:12:56PM +0100, Goffredo Baroncelli wrote:
>>>> On 2016-11-25 05:31, Zygo Blaxell wrote:
>
dn't
have an impact on the workloads.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger
On 2016-11-26 19:54, Zygo Blaxell wrote:
> On Sat, Nov 26, 2016 at 02:12:56PM +0100, Goffredo Baroncelli wrote:
>> On 2016-11-25 05:31, Zygo Blaxell wrote:
[...]
>>
>> BTW Btrfs in RAID1 mode corrects the data even in the read case. So
>
> Have you tested
RAM is bad.
BTW Btrfs in RAID1 mode corrects the data even in the read case. So I am still
convinced that is the RAID5/6 behavior "strange".
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To u
On 2016-11-22 01:28, Qu Wenruo wrote:
>
>
> At 11/22/2016 02:48 AM, Goffredo Baroncelli wrote:
>> Hi Qu,
>>
>> I tested this succefully for RAID5 when doing a scrub (i.e.: I mount a
>> corrupted disks, then I ran "btrfs scrub start ...", then I check t
fs_raid_bio *rbio,
> void *parity;
> /* first collect one page from each data stripe */
> for (stripe = 0; stripe < nr_data; stripe++) {
> - p = page_in_rbio(rbio, stripe, pagenr, 0);
> +
> + /*
> +
ation won't be a very large percentage
> of total space. A few percent of disk capacity is a fair price to pay for
> data integrity.
Both the methods would require a more aggressive balance. In this they are
equal.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint B
nux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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://vger.kernel.org/majordomo-info.html
stem
still has the older chunks which doesn't use the last inserted disk.
Is the same thing, the only differences is that the allocator should select the
chunk where to write on the basis data size to write.
> i.e. AFAIK ZFS work with storage more directly, so zfs directly span
> file to th
re-balance. But is is an issue which we already know (even if may be not 100%
addressed).
Thoughts ?
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btr
Hi Zygo
On 2016-11-18 00:13, Zygo Blaxell wrote:
> On Tue, Nov 15, 2016 at 10:50:22AM +0800, Qu Wenruo wrote:
>> Fix the so-called famous RAID5/6 scrub error.
>>
>> Thanks Goffredo Baroncelli for reporting the bug, and make it into our
>> sight.
>>
Hi Qu,
On 2016-11-15 03:50, Qu Wenruo wrote:
> Fix the so-called famous RAID5/6 scrub error.
>
> Thanks Goffredo Baroncelli for reporting the bug, and make it into our
> sight.
> (Yes, without the Phoronix report on this,
> https://www.phoronix.com/scan.php?page=news_item=Bt
o the kernel behavior 2.a) or 2.b)
>>
>> Another strangeness is that SCRUB sometime reports
>> ERROR: there are uncorrectable errors
>> and sometime reports
>> WARNING: errors detected during scrubbing, corrected
>>
>> but also these seems UNrelated to th
On 2016-07-29 08:44, Qu Wenruo wrote:
>
>
> On 07/29/2016 01:08 PM, Goffredo Baroncelli wrote:
>> On 2016-07-29 03:34, Qu Wenruo wrote:
>>>> I am not against about your proposal; however I have to point
>>>> out that the goal of these command was no
ult for unaligned input. And we spent some time to
> improve it.
>
> So I hope we can avoid such problem which has already happened in
> map-logical.
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe fro
Hi Qu,
On 2016-07-28 03:47, Qu Wenruo wrote:
> At 07/28/2016 01:43 AM, Goffredo Baroncelli wrote:
>> From: Goffredo Baroncelli <kreij...@inwind.it>
>>
>> The aim of this new command is to show the physical placement on the disk
>> of a file.
>> Currently i
Hi all,
the following patches add two new commands:
1) btrfs inspect-internal physical-find
2) btrfs inspect-internal physical-dump
The aim of these two new commands is to locate (1) and dump (2) the stripe
elements
stored on the disks. I developed these two new command to simplify the
From: Goffredo Baroncelli <kreij...@inwind.it>
The aim of this new command is to show the physical placement on the disk
of a file.
Currently it handles all the profiles (single, dup, raid1/10/5/6).
The syntax is simple:
where:
is the file to inspect
is the offset of the file to i
From: Goffredo Baroncelli <kreij...@inwind.it>
Add the following functions:
- int is_btrfs_fs(const char *path) -> returns 0 if path is a btrfs filesystem
- void check_root_or_exit() -> checks if the user has the root capability or
it exits writing an e
From: Goffredo Baroncelli <kreij...@inwind.it>
The aim of this command, is to dump the disk content of a file bypassing the
btrfs filesystem. This could help to test the btrfs filesystem.
The dump size is a page (4k) (even if the file is shorter). It is possible
to set an offset for th
From: Goffredo Baroncelli <kreij...@inwind.it>
Signed-off-by: Goffredo Baroncelli <kreij...@inwind.it>
---
Documentation/btrfs-inspect-internal.asciidoc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/btrfs-inspect-internal.asciidoc
b/Documentation/b
From: Goffredo Baroncelli <kreij...@inwind.it>
Signed-off-by: Goffredo Baroncelli <kreij...@inwind.it>
---
Documentation/btrfs-inspect-internal.asciidoc | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/btrfs-inspect-internal.asciidoc
b/Documentation/b
-
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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://vger.kernel.org/majordomo-info.html
On 2016-07-25 04:14, Qu Wenruo wrote:
> Hi Goffredo,
>
> At 07/24/2016 07:03 PM, Goffredo Baroncelli wrote:
>> Hi all,
>>
>> the following patches add two new commands: 1) btrfs
>> inspect-internal physical-find 2) btrfs inspect-internal
>> physical-dump
&
101 - 200 of 984 matches
Mail list logo
