draft

Problem reporting:

Bugs related to btrfs user-space commands should be filed against the btrfs-progs component.
RHBZ URLto prepopulate a form correctly?

All other bugs should be filed against the kernel component, while also setting the Assignee field to: fedora-kernel-btrfs@fedoraproject.org
RHBZ URLto prepopulate a form correctly?

Not a bug? Not sure? Feature request or idea?

File an issue in the Fedora Btrfs Project repository and we'll help figure things out.

(in particular I wanna know from @ngompa if this repository is an appropriate catch all)

Developers: #fedora-devel channel on irc.freenode.org; devel@lists.fpo
Users: #fedora channel on irc.freenode.org; users@lists.fpo

Idea for "what information" to get from a user. We could ask for a --btrfs flag for fpaste that gathers the extra info we want:

* OS Release (grep PRETTY_NAME /etc/os-release)
* Kernel (uname -r ; cat /proc/cmdline)
* btrfs-progs (rpm -q btrfs-progs)
* Mounts (grep btrfs /proc/mounts)
* Block devices (lsblk -ft)
* Kernel messages (journalctl -o short-monotonic --no-hostname -k) or (dmesg)
* Btrfs usage (btrfs filesystem usage -T /)
* Btrfs device stats (btrfs device stats /)

Josef is working on a complete list. But those are pretty basic and don't require privilege.

File an issue in the Fedora Btrfs Project repository and we'll help figure things out.

(in particular I wanna know from @ngompa if this repository is an appropriate catch all)

I'm not sure this repository would be a good place to put it, but I'd like feedback from @josef and @dcavalca about that idea. If they think it's fine, we can do it.

@ngompa and I chatted about it a bit ago. On second though, I think this project isn't a great catch all, and it's best to direct folks to the proper IRC channel and list, so I made those changes above in the draft.

I'd rather fedora bug reports go through the fedora bugzilla. That way there's more of us to look and triage problems. We can also point to the #btrfs irc channel on freenode, there's lots of knowledgeable help there. The things that @chrismurphy has mentioned already are a good enough start, tho I'd say all of dmesg would be good, in case there's stack traces or something.

Good point, updated to include full dmesg. Especially device issues like read errors and link resets. Already have had folks asking about installing Fedora to devices in USB-SATA enclosures (eek!)

I guess it's time to break out my 32 drive floppy raid array.

Updated the above list of info to gather.

I've got a frowny face :frowning: wondering if it's appropriate to have commands that require privilege. Without privilege fi usage is mostly complete, but lacks per device block group info, yet is still more useful than regular df. However, dev stats returns nothing without privilege, so maybe drop it?

The paste.centos.org service size limit is somewhere between 563.6KiB and 1620.5KiB. It accepted a 4000 line journal, dmesg is around 1000 lines. I think it's quite enough for this purpose.

Hi @ankursinha is this something that interests you for fpaste? I will file an RFE in bugzilla if that's preferred for tracking. This functionality is a nice to have, it's not required or urgent.

@chrismurphy lsb_release is not installed on Fedora systems by default. You probably want something like cat /etc/os-release instead.

Yes, I got that from fpaste on my F32 system. lsb_release is there. But not in F33, and fpaste there uses cat /etc/*-release | uniq

I think instead of uniq it would be adequate to use head -n 1 or grep PRETTY_NAME ?
Or just drop uniq :D

grep PRETTY_NAME would probably make it more concise. :smile:

Hi @ankursinha is this something that interests you for fpaste? I will file an RFE in bugzilla if that's preferred for tracking. This functionality is a nice to have, it's not required or urgent.

Sure. A PR would be even nicer, but an RFE will do for a start. :)

if the new commands require sudo access, we'll document that in the man page.

Consider this fixed. Enhancements made to fpaste via --btrfsinfo option. And wiki updated with bug filing info.

Outstanding, but a separate problem, we need better automation for assigning subgroups to kernel bugs. Right now it takes a person to come across a bug, or do a search, and change assignee.