The pull request you sent on Mon, 15 Jul 2019 10:57:01 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.3-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a18f8775419d3df282dd83efdb51c5a64d092f31
Thank you!
--
Deet-doot-dot, I am a bot.
I thought, I can recognize a snapshot when it has a Parent UUID, but this
is not true for snapshots of toplevel subvolumes:
root@trulla:/# btrfs version
btrfs-progs v4.5.3+20160729
root@trulla:/# btrfs subvolume show /mnt/tmp
/mnt/tmp is toplevel subvolume
root@trulla:/# btrfs subvolume snaps
On Tue, Jul 16, 2019 at 05:11:33PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 16, 2019 at 06:04:16PM +0300, Andy Shevchenko wrote:
> > +static inline void guid_copy_from_raw(guid_t *dst, const __u8 *src)
> > +{
> > + memcpy(dst, (const guid_t *)src, sizeof(guid_t));
> > +}
> > +
> > +static in
On Tue, Jul 16, 2019 at 06:04:16PM +0300, Andy Shevchenko wrote:
> +static inline void guid_copy_from_raw(guid_t *dst, const __u8 *src)
> +{
> + memcpy(dst, (const guid_t *)src, sizeof(guid_t));
> +}
> +
> +static inline void guid_copy_to_raw(__u8 *dst, const guid_t *src)
> +{
> + memcpy((g
Sometimes we may need to copy UUID from or to the raw buffer, which
is provided outside of kernel and can't be declared as UUID type.
With current API this operation will require an explicit casting
to one of UUID types and length, that is always a constant
derived as sizeof of the certain UUID typ
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Signed-off-by: Andy Shevchenko
---
fs/btrfs/ctree.h | 1 -
fs/btrfs/disk-io.c | 6 +++---
fs/btrfs/inode.c | 2 +-
f
uuid_le_gen() is no used anymore, remove it for good.
Signed-off-by: Andy Shevchenko
---
include/linux/uuid.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index b8e431d65222..7efa86a1b588 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid
Graham, Chris,
I am unable to reproduce, would you be able to try this patch and let
me know if this fixes the problem?
Thanks, Anand
On 16/7/19 9:59 PM, Anand Jain wrote:
If there are more than one path to a device, the last scanned path
will map to the mounted FS. In some Linux based o
If there are more than one path to a device, the last scanned path
will map to the mounted FS. In some Linux based os there appears to be a
system script (autofs?) which fails to notice that a device's alternative
path is already mounted, and so the change in device-path gets logged
every ~2mins wh
On Tue, Jul 16, 2019 at 04:29:27PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 16, 2019 at 4:28 PM Andy Shevchenko
> wrote:
> >
> > The following commit broke compilation
> >
> > commit d5178578bcd461cc79118c7a139882350fe505aa
> > Author: Johannes Thumshirn
> > Date: Mon Jun 3 16:58:57 2019 +02
The following commit broke compilation
commit d5178578bcd461cc79118c7a139882350fe505aa
Author: Johannes Thumshirn
Date: Mon Jun 3 16:58:57 2019 +0200
btrfs: directly call into crypto framework for checksumming
ERROR: "crc32c_impl" [fs/btrfs/btrfs.ko] undefined!
ERROR: "crc32c" [fs/btrfs/bt
On Tue, Jul 16, 2019 at 4:28 PM Andy Shevchenko
wrote:
>
> The following commit broke compilation
>
> commit d5178578bcd461cc79118c7a139882350fe505aa
> Author: Johannes Thumshirn
> Date: Mon Jun 3 16:58:57 2019 +0200
>
>btrfs: directly call into crypto framework for checksumming
>
> ERROR:
On Sat 2019-07-13 (01:17), Ulli Horlacher wrote:
> I need to find (all) subvolume directories.
> I know, btrfs subvolumes root directories have inode #256, but a
> "find / -inum 256" is horrible slow!
Because it scans also non-btrfs filesystems. This is especially a bad idea
for nfs.
I have now i
Hi,
I have now updated to kernel 5.2.1 and btrfs-progs 5.2, it didn't
change anything. (reverting back to kernels prior to 5.2 fixes the
problem)
dmesg shows:
---start cut---
[9.499103] BTRFS: device label disk1 devid 1 transid 564351 /dev/sdh1
[9.549915] BTRFS info (device sdh1): enabli
This patch will introduce ROOT_ITEM check, which includes:
- Key->objectid and key->offset check
Currently only some easy check, e.g. 0 as rootid is invalid.
- Item size check
Root item size is fixed.
- Generation checks
Generation, v2_generaetion and last_snapshot should not pass super
g
[BUG]
With fuzzed image and MIXED_GROUPS super flag, we can hitthe following
BUG_ON():
[ cut here ]
kernel BUG at fs/btrfs/delayed-ref.c:491!
invalid opcode: [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1849 Comm: sync Tainted: G O 5.2.0-custom #27
RIP: 0
There is one report of fuzzed image which leads to BUG_ON() in
btrfs_delete_delayed_dir_index().
Although that fuzzed image can already be addressed by enhanced
extent-tree error handler, it's still better to hunt down more BUG_ON().
This patch will hunt down two BUG_ON()s in
btrfs_delete_delayed
This wave has the following features:
- Hunt down BUG_ON() in btrfs_delete_delayed_dir_index()
EEXIST can cause BUG_ON(). And all callers of this function has
already handled error by aborting transacation.
- Only allocate extents from the same block group type
This is a very tricky bug, nee
> On 16 Jul 2019, at 2:46 PM, Nikolay Borisov wrote:
>
>
>
> On 16.07.19 г. 4:26 ч., Qu Wenruo wrote:
>>
>>
>> On 2019/7/15 下午11:09, Nikolay Borisov wrote:
>>>
>>>
>>> On 15.07.19 г. 17:42 ч., Anand Jain wrote:
To help debug device scan issues, add verbose option to btrfs device sca
19 matches
Mail list logo
