#634 [F33] btrfs by default test week 2020-08-31 - 2020-09-07
Closed: Fixed 3 years ago by sumantrom. Opened 3 years ago by chrismurphy.

Change proposal
RHBZ tracker bug
Workstation WG ticket

Advice is solicited from QA (and @'s) to determine goals and scope for a btrfs by default test day. If the change is approved there will be additional test days.

  1. The main change sets default_scheme = BTRFS for all desktop variants; ARM variants of desktops will have their kickstarts adjusted to produce btrfs disk images.
  2. The change proposal also lists three options (a) /boot on btrfs (b) compression (c) additional subvolumes. These won't be ready for 4 weeks.
  3. Also excluded from the change, the install media's rootfs will remain ext4.

Based only on change set (1), for getting an early lead on discovering issues with this change. Just do all the usual test cases for a default installation, for all the desktop variants, but do it with btrfs as the file system.

Example bug that was exposed first on btrfs, but turns out it's due to an assumption that /home and / are on separate file systems.

@ngompa @catanzaro @jkonecny @vponcova @javierm


Many spins have joined the proposal too, so including those test cases. These are the headlines for what to run; actual test cases I'm looking at are from FC32RC1.3 and offhand I'd say run them all. Maybe emphasis could be made to watch out for certain things? But that sorta is "leading the witness" and I'd rather just see if they run into weird stuff on their own.

Virtualization
- QA:Testcase_Install_to_Previous_KVM - might be enough
Base: Release-blocking environments (x86_64)
Base: Release-blocking environments (ARM)
Base: Modularity
Base: Non-blocking environments (x86_64)
Desktop: Release-blocking desktops: x86 / x86_64
Desktop: Release-blocking desktops: ARM
Desktop: Non release-blocking desktops: x86 / x86_64
Desktop: Non release-blocking desktops: ARM
Sugar (non-blocking, all arches)
Security Lab (should ask)

If it's a hassle for the first day to create the images we can just have folks do
QA:Testcase partitioning custom btrfs
for starters.

@chrismurphy The wiki is ready, I am working on the test day app and I will reach out for the additional test case (if any). On the side, I am running [QA:Testcase partitioning custom btrfs ]
on the latest compose to see how things work.
Are we gonna test for snapshots and other features of brtfs on this test day?
https://fedoraproject.org/wiki/Test_Day:F33_btrfs_by_default_2020-07-08

Cool thanks.

Yeah, maybe an optional test? User creates subvolume in ~/ and fallocates a large file in it. Then snapshots a few times. Now meander around the desktop and apps that do space reporting, and sanity check.

Cool thanks.
Yeah, maybe an optional test? User creates subvolume in ~/ and fallocates a large file in it. Then snapshots a few times. Now meander around the desktop and apps that do space reporting, and sanity check.

Roger that, I will write up something as an optional test case

I wonder if the actual test day should just be 'Btrfs test day', or 'Desktop on Btrfs test day'? I named the QA ticket after the change proposal. But it's not an accepted change so it seems presumptuous. Any ideas? I guess it also depends on whether we use test day specific media or just use custom partitioning.

@chrismurphy the test day is set around any changeset and we have named it mostly in association with the proposal name. It doesn't really matter if it's accepted on not, if it's a changeset and we want to gather some feedback around, i would still like to keep it btrfs by default. However, I will hold my breath for @adamwill and @kparal views on this

Metadata Update from @sumantrom:
- Issue assigned to sumantrom
- Issue tagged with: test days

3 years ago

I wonder if we should explicitly invite folks to do testing on VM's to avoid running into difficulty with Custom partitioning? We do need baremetal testing too so I don't want to detour people from doing that, but custom partitioning is much easier to an empty disk than it is to have to do a partial tear down to make space.

Eek! I missed this whole section of test cases.
- Guided storage configuration

Eek! I missed this whole section of test cases.
- Guided storage configuration

No issues will be fixed in a couple of mins

Eek! I missed this whole section of test cases.
- Guided storage configuration

Updated : https://testdays.fedorainfracloud.org/events/88 with all Guided test cases

@chrismurphy, @kparal and @sumantrom are wondering when can we have another test day ?
Also, we have some ideas to suggest users to test:
1. Having two different types of storage types like, most of the users these days have a SSD and an additional HDD.
2. Testing with two different types of partitions
3. Dual boots with current stable and F31
Other than these, we are asking desktop team to put as many corner cases.. so we can write up test cases which ensure some degrees of better coverage

Also since there are opetions like defrag the disk at certain intervals as feature, @kparal proposed that we should ensure there is a default value that is followed by the upstream and if we are supposed to change those in WS then we must have that covered in some test case as well.

Kernel 5.8 is just out. About the earliest I expect to see kernel 5.9-rc1 is August 17. There won't be any big new Btrfs features, just fixes and performance improvements. We can test using either kernel, but may end up finding bugs (video, wifi) other than Btrfs if we use only an early rc kernel.

I'm not aware of any plan for scheduled defragmenting by default. There is an idea to set autodefrag with an XATTR on specific directories if the drive is (a) self-reports as rotational, and (b) SCSI-based including SAS or SATA, i.e. not USB.

I'm working on a Fedora Magazine article as my top priority, and tentatively plan to incorporate recruitment for the test week. A completely separate Fedora Magazine article, in the Kernel Test Week style, can be land before or after. But maybe we should schedule some time to talk about the test day parameters at either the next QA meeting or plan to chat about it on #fedora-qa?

We have agreed upon dates for a btrfs in Fedora test week: 31 Aug - 7 Sep.

Updates:

  • Fedora 33 will ship with kernel 5.8. Rebase to 5.9 will happen soon after GA.
  • Compression and autodefrag won't be enabled by default anywhere, for F33.
  • Fedora Magazine article Btrfs Coming to Fedora 33 will publish Monday but doesn't have any test recruitment component. We might want a separate short article to do that.

Test ideas:

It's a guessing game to try to discover an issue that's both new and likely. If I suggest areas where I think we could find issues, then we might end up biasing the testing to look for obscure things that end up not being relevant to release standards. But I'm happy to help suggest ways of sabotaging things upon request, because I definitely do not think the Change should be treated with kid gloves.

We have agreed upon dates for a btrfs in Fedora test week: 31 Aug - 7 Sep.

Updates:

  • Fedora 33 will ship with kernel 5.8. Rebase to 5.9 will happen soon after GA.
  • Compression and autodefrag won't be enabled by default anywhere, for F33.
  • Fedora Magazine article Btrfs Coming to Fedora 33 will publish Monday but doesn't have any test recruitment component. We might want a separate short article to do that.

Test ideas:

It's a guessing game to try to discover an issue that's both new and likely. If I suggest areas where I think we could find issues, then we might end up biasing the testing to look for obscure things that end up not being relevant to release standards. But I'm happy to help suggest ways of sabotaging things upon request, because I definitely do not think the Change should be treated with kid gloves.

Hey Chris,

Thanks for updating. One more question, we will be using the latest F33 for this test day right?

we will be using the latest F33 for this test day right?

Yes. I'd say a clean install from any nightly since branch, with updates installed, is fine. A specific test day image isn't needed.

My #1 wish list for this test week is really for folks to install and commit to using it normally for a week and report any and all issues, concerns, questions that come up. It's an unusual test case but the one most likely to reveal overlooked problems, in particular integration, I think.

Installer, suspend to RAM, and suspend to disk, are also very relevant tests to focus on.

What about incorporating docs review? I'm thinking just identify stale/misleading things for update, not asking folks to fix it up (unless they want to).

Hopefully, we will have a draft troubleshooting/repair sequence advice by next week.

The announcement says:

  1. Install use it normally for a week and report any and all issues,
    concerns, questions that come up
  2. Testing the BlivetGUI installer options along with the Custom
  3. Suspend to RAM
  4. Suspend to Disk
  5. Reinstalling F33 on an installed Fedora partition and preserving
    /home and its data
  6. Help find outdated docs and report them to QA team and WS team

I'm not really seeing any test cases for 2, 3, 4 and 6. Shouldn't they be there?

The announcement says:

  1. Install use it normally for a week and report any and all issues,
    concerns, questions that come up
  2. Testing the BlivetGUI installer options along with the Custom
  3. Suspend to RAM
  4. Suspend to Disk
  5. Reinstalling F33 on an installed Fedora partition and preserving
    /home and its data
  6. Help find outdated docs and report them to QA team and WS team

I'm not really seeing any test cases for 2, 3, 4 and 6. Shouldn't they be there?

2 is updated on the test matrices
3,4 is being worked on and 6 will be on the expolatory testing

There's swaponzram test cases that mostly fit for 3 and 4. Once change, use systemctl suspend and systemctl hibernate.

Maybe add this
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_rescue_mode

Fedora-Everything-netinst-x86_64-33-20200829.n.0.iso does rescue a custom btrfs layout.

The BTRFS test week happened and we had 1020 test runs and 105 testers participating.
Test results have been moved to https://fedoraproject.org/wiki/Test_Day:2020-08-31_Btrfs_default#Test_Results

Metadata Update from @sumantrom:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata