On 2016-08-04 17:12, Chris Murphy wrote:
On Thu, Aug 4, 2016 at 2:51 PM, Martin <rc6encryp...@gmail.com> wrote:
Thanks for the benchmark tools and tips on where the issues might be.
Is Fedora 24 rawhide preferred over ArchLinux?
I'm not sure what Arch does any differently to their kernels from
kernel.org kernels. But bugzilla.kernel.org offers a Mainline and
Fedora drop down for identifying the kernel source tree.
IIRC, they're pretty close to mainline kernels. I don't think they have
any patches in the filesystem or block layer code at least, but I may be
wrong, it's been a long time since I looked at an Arch kernel.
If I want to compile a mainline kernel. Are there anything I need to tune?
Fedora kernels do not have these options set.
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
The sanity and integrity tests are both compile time and mount time
options, i.e. it has to be compiled enabled for the mount option to do
anything. I can't recall any thread where a developer asked a user to
set any of these options for testing though.
FWIW, I actually have the integrity checking code built in on most
kernels I build. I don't often use it, but it has near zero overhead
when not enabled, and it's helped me track down lower-level storage
configuration issues on occasion.
When I do the tests, how do I log the info you would like to see, if I
find a bug?
bugzilla.kernel.org for tracking, and then reference the URL for the
bug with a summary in an email to list is how I usually do it. The
main thing is going to be the exact reproduce steps. It's also better,
I think, to have complete dmesg (or journalctl -k) attached to the bug
report because not all problems are directly related to Btrfs, they
can have contributing factors elsewhere. And various MTAs, or more
commonly MUAs, have a tendancy to wrap such wide text as found in
kernel or journald messages.
Aside from kernel messages, the other general stuff you want to have is:
1. Kernel version and userspace tools version (`uname -a` and `btrfs
--version`)
2. Any underlying storage configuration if it's not just plain a SSD/HDD
or partitions (for example, usage of dm-crypt, LVM, mdadm, and similar
things).
3. Output from `btrfs filesystem show` (this can be trimmed to the
filesystem that's having the issue).
4. If you can still mount the filesystem, `btrfs filesystem df` output
can be helpful.
5. If you can't mount the filesystem, output from `btrfs check` run
without any options will usually be asked for.
--
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
