On Mon, Sep 17, 2018 at 11:24 PM, Andrei Borzenkov wrote:
> 18.09.2018 07:21, Chris Murphy пишет:
>> On Mon, Sep 17, 2018 at 9:44 PM, Chris Murphy
>> wrote:
>>> https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
>>>
>>> Does anyone know if this is still a problem on Btrfs if
On 2018/9/17 下午9:24, Su Yue wrote:
>
>
> On 2018/9/17 8:53 PM, Qu Wenruo wrote:
>>
>>
>> On 2018/9/17 下午3:28, Su Yue wrote:
>>> After call of check_inode_item(), path may point to the last unchecked
>>> slot of the leaf. The outer walk_up_tree() always treats the position
>>> as checked slot
18.09.2018 07:21, Chris Murphy пишет:
> On Mon, Sep 17, 2018 at 9:44 PM, Chris Murphy wrote:
>> https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
>>
>> Does anyone know if this is still a problem on Btrfs if grubenv has
>> xattr +C set? In which case it should be possible to
sunny.s.zhang posted on Tue, 18 Sep 2018 08:28:14 +0800 as excerpted:
> My OS(4.1.12) panic in kmem_cache_alloc, which is called by
> btrfs_get_or_create_delayed_node.
>
> I found that the freelist of the slub is wrong.
[Not a dev, just a btrfs list regular and user, myself. But here's a
On Mon, Sep 17, 2018 at 9:44 PM, Chris Murphy wrote:
> https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
>
> Does anyone know if this is still a problem on Btrfs if grubenv has
> xattr +C set? In which case it should be possible to overwrite and
> there's no csums that are
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
Does anyone know if this is still a problem on Btrfs if grubenv has
xattr +C set? In which case it should be possible to overwrite and
there's no csums that are invalidated.
I kinda wonder if in 2018 it's specious for,
Modify the file name length limit to meet the Linux naming convention.
In addition, the file name length is always bigger than 0, no need to
compare with 0 again.
Changelog:
v2:
Fix the same problem in creating snapshot routine.
Issue: #145
Signed-off-by: Su Yanjun
---
v2: Also fix the same
Sorry, modify some errors:
Process A (btrfs_evict_inode) Process B
call btrfs_remove_delayed_node call
btrfs_get_delayed_node
node = ACCESS_ONCE(btrfs_inode->delayed_node);
BTRFS_I(inode)->delayed_node = NULL;
Hi All,
My OS(4.1.12) panic in kmem_cache_alloc, which is called by
btrfs_get_or_create_delayed_node.
I found that the freelist of the slub is wrong.
crash> struct kmem_cache_cpu 887e7d7a24b0
struct kmem_cache_cpu {
freelist = 0x2026, <<< the value is id of one inode
tid =
thank you.
在 2018年09月18日 08:18, Hans van Kranenburg 写道:
On 09/18/2018 02:13 AM, sunny.s.zhang wrote:
Can anyone receive this message? I found i can receive message from the
mail list, but can't receive message that send by myself.
Yes.
You can also check public list archives to see if your
On 09/18/2018 02:13 AM, sunny.s.zhang wrote:
>
> Can anyone receive this message? I found i can receive message from the
> mail list, but can't receive message that send by myself.
Yes.
You can also check public list archives to see if your message shows up,
e.g.:
Hi All,
Can anyone receive this message? I found i can receive message from the
mail list, but can't receive message that send by myself.
Thanks,
Sunny
On Fri, Sep 14, 2018 at 06:38:44PM +0200, David Sterba wrote:
> The helper find_lock_delalloc_range is now conditionally built static,
> dpending on whether the self-tests are enabled or not. There's a macro
> that is supposed to hide the export, used only once. To discourage
> further use, drop
On Fri, Sep 14, 2018 at 06:42:03PM +0200, David Sterba wrote:
> Avoid the inline ifdefs and use two sections for self-tests enabled and
> disabled.
>
> Though there could be no ifdef and unconditional test_bit of
> BTRFS_FS_STATE_DUMMY_FS_INFO, the static inline can help to optimize out
> any
On 17.09.2018 10:28, Su Yue wrote:
> inode_extref is much similar with inode_ref, most codes are reused in
> check_inode_extref().
> Exceptions:
> There is no need to check root directory, so remove it.
> Make check_inode_extref() verify hash value with key offset now.
>
> And lowmem check can
On 2018/9/17 8:53 PM, Qu Wenruo wrote:
On 2018/9/17 下午3:28, Su Yue wrote:
After call of check_inode_item(), path may point to the last unchecked
slot of the leaf. The outer walk_up_tree() always treats the position
as checked slot then skips to the next. The last item will never be
On 17.09.2018 15:51, Qu Wenruo wrote:
>
>
> On 2018/9/17 下午3:28, Su Yue wrote:
>> In check_fs_roots_lowmem(), we do search and follow the resulted path
>> to call check_fs_root(), then call btrfs_next_item() to check next
>> root.
>> However, if repair is enabled, the root tree can be cowed,
On 2018/9/17 下午8:55, Su Yue wrote:
>
>
> On 2018/9/17 8:51 PM, Qu Wenruo wrote:
>>
>>
>> On 2018/9/17 下午3:28, Su Yue wrote:
>>> In check_fs_roots_lowmem(), we do search and follow the resulted path
>>> to call check_fs_root(), then call btrfs_next_item() to check next
>>> root.
>>> However,
On 2018/9/17 下午3:28, Su Yue wrote:
> inode_extref is much similar with inode_ref, most codes are reused in
> check_inode_extref().
> Exceptions:
> There is no need to check root directory, so remove it.
As root directory should only have one INODE_REF "..", so it shouldn't
have any extref at
> If your primary concern is to make the fs as stable as possible, then
> keep snapshots to a minimal amount, avoid any functionality you won't
> use, like qgroup, routinely balance, RAID5/6.
>
> And keep the necessary btrfs specific operations to minimal, like
> subvolume/snapshot (and don't
On 2018/9/17 8:51 PM, Qu Wenruo wrote:
On 2018/9/17 下午3:28, Su Yue wrote:
In check_fs_roots_lowmem(), we do search and follow the resulted path
to call check_fs_root(), then call btrfs_next_item() to check next
root.
However, if repair is enabled, the root tree can be cowed, the
existed
On 2018/9/17 下午3:28, Su Yue wrote:
> After call of check_inode_item(), path may point to the last unchecked
> slot of the leaf. The outer walk_up_tree() always treats the position
> as checked slot then skips to the next. The last item will never be
> checked.
>
> While checking backrefs, path
On 2018/9/17 下午3:28, Su Yue wrote:
> In check_fs_roots_lowmem(), we do search and follow the resulted path
> to call check_fs_root(), then call btrfs_next_item() to check next
> root.
> However, if repair is enabled, the root tree can be cowed, the
> existed path can cause strange errors.
>
>
On 2018/9/17 下午3:28, Su Yue wrote:
> In check_dir_item, we are going to search corresponding
> dir_item/index.
>
> Commit 564901eac7a4 ("btrfs-progs: check: introduce
> print_dir_item_err()") Changed argument name from key to di_key but
> forgot to change the key name for dir_item search.
> So
On 2018/9/17 下午7:55, Adrian Bastholm wrote:
>> Well, I'd say Debian is really not your first choice for btrfs.
>> The kernel is really old for btrfs.
>>
>> My personal recommend is to use rolling release distribution like
>> vanilla Archlinux, whose kernel is already 4.18.7 now.
>
> I just
> Well, I'd say Debian is really not your first choice for btrfs.
> The kernel is really old for btrfs.
>
> My personal recommend is to use rolling release distribution like
> vanilla Archlinux, whose kernel is already 4.18.7 now.
I just upgraded to Debian Testing which has the 4.18 kernel
>
On 16/09/18, Chris Murphy (li...@colorremedies.com) wrote:
> On Sun, Sep 16, 2018 at 12:40 PM, Rory Campbell-Lange
> wrote:
> > I'm a bit confused about the difference between / and backup, which is
> > at /bkp/backup.
>
> top level, subvolid=5, subvolid=0, subvol=/, FS_TREE are all the same
>
In check_fs_roots_lowmem(), we do search and follow the resulted path
to call check_fs_root(), then call btrfs_next_item() to check next
root.
However, if repair is enabled, the root tree can be cowed, the
existed path can cause strange errors.
Solution:
If repair, save the key before calling
Inode 257 is only with inode_extref without inode_ref.
And This case contains an inode_extref:
==
...
item 1 key (257 INODE_EXTREF 3460996356) itemoff 3947 itemsize 24
index 257 parent 256 namelen 6 name: foo255
...
The argument index is not used in btrfs_lookup_inode_extref(),
so remove it.
And adjust positions its arguments to make it consistent with
kernel part.
No functional change.
Fixes: 260675657767 ("btrfs-progs: Import btrfs_insert/del/lookup_extref()
functions.")
Signed-off-by: Su Yue
inode_extref is much similar with inode_ref, most codes are reused in
check_inode_extref().
Exceptions:
There is no need to check root directory, so remove it.
Make check_inode_extref() verify hash value with key offset now.
And lowmem check can detect errors about inode_extref and try to
repair
btrfs_unlink() uses btrfs_lookup_inode_ref() to look up inode_ref
but forget inode_extref case.
Let btrfs_unlink() call btrfs_lookup_inode_extref() if inode_ref is
found and EXTENDED_IREF feature is enabled.
Fixes: 0cc75eddd093 ("btrfs-progs: Add btrfs_unlink() and btrfs_add_link()
functions.")
After call of check_inode_item(), path may point to the last unchecked
slot of the leaf. The outer walk_up_tree() always treats the position
as checked slot then skips to the next. The last item will never be
checked.
While checking backrefs, path passed to walk_up_tree() always
points to a
In check_dir_item, we are going to search corresponding
dir_item/index.
Commit 564901eac7a4 ("btrfs-progs: check: introduce
print_dir_item_err()") Changed argument name from key to di_key but
forgot to change the key name for dir_item search.
So @key shouldn't be used here. It should be @di_key.
This patchset can be fetched from my github:
https://github.com/Damenly/btrfs-progs/tree/lowmem_extref
based on kdave/devel whose HEAD is:
commit 4f20c27ab33aab3efffe13cdae1b8837c821d0d7 (kdave/devel)
Author: Nikolay Borisov
Date: Fri Jun 15 07:13:50 2018 +
btrfs-progs: tests: test for FST
35 matches
Mail list logo
