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
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"
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
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,
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:
>>>
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-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)
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
.
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
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
--
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 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
>&
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
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
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.
&
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-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
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
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
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
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
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
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
>
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 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
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
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-
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
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
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
. 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
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
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
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
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
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
> +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
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
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
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.
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-
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
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
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
(argc < 2) {
>> fprintf(stderr, "usage: %s \n", argv[0]);
>> exit(100);
>> }
>>
>>
>> buffer = mmap(NULL, FILESIZE,
>> PROT_READ|PROT_WRITE,
>> MAP_SHARE
in
0+0 records out
0 bytes copied, 0.000404156 s, 0.0 kB/s
ghigo@venice:~/btrfs/crash-o-direct/t$ dmesg -T | tail -1
[Sat Sep 16 13:56:41 2017] BTRFS warning (device sdd5): csum failed root 5 ino
257 off 0 csum 0x98f94189 expected csum 0x0ab6be80 mirror 1
>
> Signed-off-by: Liu Bo <bo.
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
check around "btrfs sub del", so an user can remove an _empty_
subvolume
https://www.spinics.net/lists/linux-btrfs/msg06522.html
>
>
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe f
rted in kernel log
> 2) read(2) returns successfully with some content being 0x01.
>
> In order to fix it, we need to report its checksum mismatch error to
> the upper layer (dio layer in this case) as well.
>
> Signed-off-by: Liu Bo <bo.li@oracle.com>
> Reporte
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
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
>
> This is the explantion why it does not work, but it does not help me. I
> still have the problem: how can a user get a list of his subvolumes? He
> may created them some time ago and forget it. He now wants to have a list
> of them.
Far to be perfect, but this could help
find
From: Goffredo Baroncelli <kreij...@inwind.it>
The function load_chunk_info() doesn't initialize correctly the
sk->min/max_type when it calls the TREE_SEARCH ioctl: these keys are swapped.
Moreover this function assumes that all the items contained in the tree
BTRFS_CHUNK_TREE
The function load_chunk_info() doesn't initialize correctly the
sk->min/max_type when it calls the TREE_SEARCH ioctl: these keys are swapped.
Moreover this function assumes that all the items contained in the tree
BTRFS_CHUNK_TREE_OBJECTID are of type BTRFS_CHUNK_ITEM_KEY, however some
items are
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);
On 10/02/2017 11:46 PM, Goffredo Baroncelli wrote:
> which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF ==
> Support for large (2TB+) block devices and files)
Only now I noticed that in the first email you attached the config; in fact in
your config CONFIG_LBDAF is n
bio = btrfs_bio_alloc(bdev, sector << 9);
with
bio = btrfs_bio_alloc(bdev, (u64)sector << 9);
[1]
http://elixir.free-electrons.com/linux/latest/source/fs/btrfs/extent_io.c#L2762
[2]
http://elixir.free-electrons.com/linux/latest/source/include/linux/types.h#L133
>
>
a lot (about 24+7+4 = 35 times)
>
> Thanks,
> Niccolò
BR
G.Baroncelli
> --
> 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-
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 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 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
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
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
remove this feature, it needs fix such as #2 (above) to improve on
> #1 (above) as in your list.
>
> Thanks, Anand
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo
sub1 ID = 538
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.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
environment, but I suppose that
also on the bare metal it will be quite quick.
BR
G.Baroncelli
>
>
>
> Am 30.09.2017 um 09:16 schrieb Goffredo Baroncelli:
>> On 09/30/2017 01:06 AM, DocMAX wrote:
>>>>> Did you removed the disk before mounting (physically or doing echo
/tmp/test1/test3 ID = 535
/debian/tmp/test1.snap2 ID = 536
/test ID = 537
/test/sub1 ID = 538
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
To
> same i/o error
>
Did you switch off the machine ? If not, before mounting in degraded mode, do
"echo 1 >/sys/block/xxx/device/delete". After the monting do a btrfs dev del
missing
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B
make a usable filesystem
ERROR: minimum size for each btrfs device is 41943040
you have to create a big enough
ghigo@venice:/tmp$ truncate -s 10G disk.img
ghigo@venice:/tmp$ mkfs.btrfs --root test disk.img
btrfs-progs v4.12
See http://btrfs.wiki.kernel.org for more information.
[...]
BR
--
gpg @keys
earching a way to handle the snapshots which fully
satisfy me (putting them under /, is not the best)
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-
On 09/28/2017 02:00 AM, Qu Wenruo wrote:
>
>
> On 2017年09月28日 00:20, David Sterba wrote:
>> On Mon, Sep 25, 2017 at 07:15:30AM -0400, Austin S. Hemmelgarn wrote:
>>> On 2017-09-24 10:08, Goffredo Baroncelli wrote:
>>>> On 09/24/2017 12:10 PM, Ana
1.82TiB
>Device slack: 0.00B
>Data,RAID5:333.00GiB
>Data,RAID5:955.00GiB
>Data,RAID5: 5.57GiB
>Metadata,RAID1: 3.00GiB
> Unallocated: 566.44GiB
>
> Thanks,
> DocMAX
>
re-format.
No, it should not be necessary.
>
>
>
> Am 29.09.2017 um 23:04 schrieb Goffredo Baroncelli:
>> On 09/29/2017 10:00 PM, Dirk Diggler wrote:
>>> Hi,
>>>
>>> is there any chance to get my device removed?
>> I simulated a device removing in
From: Goffredo Baroncelli <kreij...@inwind.it>
Jean-Denis Girard noticed commit c821e7f3 "pass bytes to
btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/) introduces a
regression on 32 bit machines.
When CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == Support for la
From: Goffredo Baroncelli <kreij...@inwind.it>
Add a new ioctl to get info about chunk without requiring the root privileges.
This allow to a non root user to know how the space of the filesystem is
allocated.
Signed-off-by: Goffredo Baroncelli <kreij...@inwind.it>
---
fs/b
li
--
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.
From: Goffredo Baroncelli <kreij...@inwind.it>
Use the new ioctl BTRFS_IOC_GET_CHUNK_INFO in load_chunk_info() instead of the
BTRFS_IOC_TREE_SEARCH. The old method is still present as fallback for
compatibility reason.
The goal is to avoid BTRFS_IOC_GET_CHUNK_INFO because it require
From: Goffredo Baroncelli <kreij...@inwind.it>
Allow the get_partition_size() to be called without
root privileges.
Signed-off-by: Goffredo baroncelli <kreij...@inwind.it>
---
utils.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git
he api is a good api. In particular I am not sure that returning -EAGAIN is
the right thing to do when further data is available but the buffer is not
enough.
Comments are welcome
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2
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
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
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
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..
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
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
On 10/04/2017 07:13 PM, Liu Bo wrote:
> On Wed, Oct 04, 2017 at 04:22:28PM +0200, David Sterba wrote:
>> On Tue, Oct 03, 2017 at 07:31:10PM +0200, Goffredo Baroncelli wrote:
>>> From: Goffredo Baroncelli <kreij...@inwind.it>
>>>
>>> Jean-Denis
Because the filesystem is a raid1, btrfs may read from /dev/sdb (updated data)
or /dev/sda (old data), or worse read something from the former and something
from the later (metadata from sda and data from sdb ) ???
Am I missing something ?
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo B
On 11/20/2017 09:19 AM, Anand Jain wrote:
>
>
> On 11/18/2017 09:52 PM, Goffredo Baroncelli wrote:
>> On 11/17/2017 01:36 PM, Anand Jain wrote:
>>> If the device is not present at the time of (-o degrade) mount,
>>> the mount context will create a dummy missi
On 12/05/2017 09:17 PM, Austin S. Hemmelgarn wrote:
> On 2017-12-05 14:09, Goffredo Baroncelli wrote:
>> On 12/05/2017 07:46 PM, Graham Cobb wrote:
>>> On 05/12/17 18:01, Goffredo Baroncelli wrote:
>>>> On 12/05/2017 04:42 PM, Graham Cobb wrote:
>> []
&
/quota info for accessible
> subvolumes
> ==
>
> --
> 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
>
[1] h
't have write access to the parent directory. I assume that this is a
POSIX requirement; and if so this should be true even for BTRFS.
This means that in order to remove a subvolume and you are not root, you should
check all the contained directories. It is not sufficient to check one inode.
In the
801 - 900 of 984 matches
Mail list logo
