One of btrfs tests, btrfs/011, uses SCRATCH_DEV_POOL and puts a
non-SCRATCH_DEV device as the first one when doing mkfs, and this makes
_require_scratch{_nocheck} confused since it checks mount point with
SCRATCH_DEV only.
This adds _scratch_umount to cleanup() to umount SCRATCH_MNT by
011
This test, btrfs/027, runs tests against different raid profiles
in a loop, if one of them aborts, it also fails the following ones
with errors like,
Test -m raid10 -d raid10
ERROR: /dev/xxx is mounted
Test -m raid5 -d raid5
ERROR: /dev/xxx is mounted
Test -m raid6 -d raid6
ERROR: /dev/xxx is
On Tue, Jan 16, 2018 at 9:45 AM, Chris Murphy wrote:
...
>>
>> Unless some better fix is in the works, this _should_ be a systemd unit or
>> something. Until then, please put it in FAQ.
>
> At least openSUSE has a systemd unit for a long time now, but last
> time I
On 2018-01-16 18:22:14 [+0800], Qu Wenruo wrote:
> Btrfs check is always recommended before really mount it.
# btrfs check -p /dev/sdb4
Checking filesystem on /dev/sdb4
UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
checking extents [O]
cache and super generation don't match, space cache will
On 01/16/2018 03:26 AM, David Sterba wrote:
On Fri, Jan 12, 2018 at 06:14:40PM +0800, Anand Jain wrote:
Misono,
This change is causing subsequent (subvol) mount to fail when device
option is specified. The simplest eg for failure is ..
mkfs.btrfs -qf /dev/sdc /dev/sdb
mount
On 16 January 2018 05:51:23 CET, Qu Wenruo wrote:
>Since there is no other hit, I assume it's root subvolume (5), but I
>still need the extra confirm since the fix will be hard-coded.
Yes, 5 is correct.
>
>Thanks,
>Qu
Sebastian
--
To unsubscribe from this list: send
On 2018年01月16日 18:10, Sebastian Andrzej Siewior wrote:
> On 2018-01-16 13:19:50 [+0800], Qu Wenruo wrote:
>> Usage:
>> ./btrfs-corrupt-block -X
> # ./btrfs-corrupt-block -X /dev/sdb4
> Fix is done successfully
>
> may I mount it now or should I run btrfs check or something first?
Btrfs check
On 2018年01月16日 18:49, Sebastian Andrzej Siewior wrote:
> On 2018-01-16 18:22:14 [+0800], Qu Wenruo wrote:
>> Btrfs check is always recommended before really mount it.
>
> # btrfs check -p /dev/sdb4
> Checking filesystem on /dev/sdb4
> UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1
> checking
On 2018-01-16 13:19:50 [+0800], Qu Wenruo wrote:
> Usage:
> ./btrfs-corrupt-block -X
# ./btrfs-corrupt-block -X /dev/sdb4
Fix is done successfully
may I mount it now or should I run btrfs check or something first?
> Thanks,
> Qu
Sebastian
--
To unsubscribe from this list: send the line
On 2018-01-16 01:45, Chris Murphy wrote:
On Mon, Jan 15, 2018 at 11:23 AM, Tom Worster wrote:
On 13 Jan 2018, at 17:09, Chris Murphy wrote:
On Fri, Jan 12, 2018 at 11:24 AM, Austin S. Hemmelgarn
wrote:
To that end, I propose the following text for
On Fri, Jan 12, 2018 at 04:21:05PM +0200, Nikolay Borisov wrote:
> The behavior of btrfs_delalloc_reserve_metadata depends on whether
> the inode we are allocating for is the freespace inode or not. As it
> stands if we are the free node we set 'flush' and 'delalloc_lock'
> variable to certain
On Fri, Jan 12, 2018 at 11:08:03AM +0800, Su Yue wrote:
> There is no function named btrfs_get_inode_index_count.
> Explanation for magic number index_cnt=2 in btrfs_new_inode() is
> actually located in btrfs_set_inode_index_count().
>
> So replace 'btrfs_get_inode_index_count' in the comment by
On 15.01.2018 08:13, Qu Wenruo wrote:
> Enospc_debug makes extent allocator to print more debug messages,
> however for chunk allocation, there is no debug message for enospc_debug
> at all.
>
> This patch will add message for the following parts of chunk allocator:
>
> 1) No rw device at all
On 2018年01月16日 21:47, Nikolay Borisov wrote:
>
>
> On 15.01.2018 08:13, Qu Wenruo wrote:
>> Enospc_debug makes extent allocator to print more debug messages,
>> however for chunk allocation, there is no debug message for enospc_debug
>> at all.
>>
>> This patch will add message for the
Sebastian reported a filesystem corruption where DIR_INDEX has wrong
filetype against INODE_ITEM.
Lowmem mode normally handles such problem by checking DIR_INDEX,
DIR_ITEM and INODE_REF/INODE_ITEM to determine the correct file type.
In such case, lowmem mode fsck can get the correct filetype.
For functions btrfs_lookup_dir_index() and btrfs_lookup_dir_item(), they
will check if the dir item/index is valid before doing further check.
The behavior is pretty good for healthy fs, but calling them on
corrupted fs with incorrect dir item/index will also return NULL, making
repair code
For repair_ternary_lowmem() used in lowmem mode, if it found 1 of
DIR_INDEX/DIR_ITEM/INODE_REF missing, it will try to insert correct
link.
However for case like invalid type in DIR_INDEX, we should delete the
corrupted DIR_INDEX first before inserting the correct link.
This patch will remove
Function btrfs_delete_one_dir_name() will check if the dir_item is the
last content of the item, and delete the whole item if needed.
However if @name_len of one dir_item/dir_index is corrupted and larger
than the item size, the function will still try to treat it as partly
remove, which will
Hi David,
There is the long planned work to split the original mode and lowmem
mode check into their own .[ch] files.
I found it harder and harder to locate repair functions for original and
lowmem mode when writing fixes for them.
I wonder if it's a good time to start the split work, and if
On 2018-01-16 19:20:56 [+0800], Qu Wenruo wrote:
> This is a very minor problem.
>
> btrfs check --repair should handle it without problem.
awesome, thank you! After the --repair completed, the following didn't
report the error anymore. And now I was able to remove the two files.
Thank you.
>
On 2018年01月16日 20:15, Sebastian Andrzej Siewior wrote:
> On 2018-01-16 19:20:56 [+0800], Qu Wenruo wrote:
>> This is a very minor problem.
>>
>> btrfs check --repair should handle it without problem.
>
> awesome, thank you! After the --repair completed, the following didn't
> report the error
21 matches
Mail list logo