> bh = btrfs_read_dev_super(fs_devices->latest_bdev);
> if (!bh) {
> err = -EINVAL;
> goto fail_alloc;
> }
>
> memcpy(&fs_info->super_copy, bh->b_data, sizeof(fs_info->super_copy));
> memcpy(&fs_info->super_for_commit, &fs_inf
On Thu, 02 Jun 2011 13:17:55 -0700
Andi Kleen wrote:
> Sergei Trofimovich writes:
> >
> > Am I too paranoid about the issue?
>
> It sounds weird, because if the kernel would really checksum
> mutexes on disk you would have a lot of on disk
> format incompatibility between different kernel versi
Sergei Trofimovich writes:
>
> Am I too paranoid about the issue?
It sounds weird, because if the kernel would really checksum
mutexes on disk you would have a lot of on disk
format incompatibility between different kernel versions
(e.g. between lockdep and normal kernels or kernels
running on di
Some clarifications:
> Patchset based on 'tmp' branch e6bd18d8938986c997c45f0ea95b221d4edec095.
All patches are against btrfs-progs.
The rest of rambling is about kernel code, which handles supers.
I have read what I've wrote last night (braindump of insane!)
and will try to elaborate a bit
Hello friends!
tmp branch recently got very nice feature: 'mkfs.btrfs -r /some/directory'.
It's very useful, when you need to creare minimal root: sh and fs_mark.
But there is another hidden feature! As '-r' can create whole filesystem
we can effectively valgrind a lot of code paths in btrfs and
