-- Forwarded message -
Från: Leslie Satenstein via devel
Date: mån 5 feb. 2024 kl 17:23
Subject: Rawhide Beta Everything.iso and other ISOs -- btrfs -- serious issue
To: de...@lists.fedoraproject.org
Cc: Leslie Satenstein
I am not registered as an official test person. But I
=usebackuproot" this is also used by rescue=all, but
permits rw mount. If it works, the current damaged root tree will be replaced
by a good one.
> btrfs rescue zero-log
> btrfs check --repair --init-extent-tree
> btrfs check --repair
I don't think any of these are indicated
this problematic filesystem. Is it time to run them?
Try "mount -o rescue=usebackuproot" this is also used by rescue=all, but
permits rw mount. If it works, the current damaged root tree will be replaced
by a good one.
> btrfs rescue zero-log
> btrfs check --repair --init-extent-tree
>
.
From
"https://lists.fedoraproject.org/archives/search?mlist=users%40lists.fedoraproject.org&q=parent+transid+verify+failed";
I found some other commands that you wrote. I presume after unmounting this
problematic filesystem. Is it time to run them? I'm not sure what they
gt;> can fix itself. If it gets confused again, it'll go read only to avoid
>> making things worse.
>
> This mount is just a one time thing, assuming it works. You can just
> umount, and then reboot normally.
Also, generally easier to ask for me (cmurf) on
https://matrix.to/#/
On Mon, Aug 22, 2022, at 11:46 AM, Chris Murphy wrote:
> After that, you can umount the file system. And mount again with '-o
> rescue=usebackuproot' and hopefully it finds a good backup root, and
> can fix itself. If it gets confused again, it'll go read only to avoid
> making things worse.
#x27;s path
> being in /etc/fstab.
>
> I need some help with this please. Here is what mount says:
>
> mount /dev/sda6 /opt.
>
> kernel: BTRFS info (device sda6): flagging fs with big metadata feature
> kernel: BTRFS info (device sda6): disk space caching is enabled
&g
system. This might have been the wrong thing to do. This
> subsequent boot went to maintenance mode due the filesystem's path
> being in /etc/fstab.
>
> I need some help with this please. Here is what mount says:
>
> mount /dev/sda6 /opt.
>
> kernel: BTRFS info (de
says:
mount /dev/sda6 /opt.
kernel: BTRFS info (device sda6): flagging fs with big metadata feature
kernel: BTRFS info (device sda6): disk space caching is enabled
kernel: BTRFS info (device sda6): has skinny extents
kernel: BTRFS error (device sda6): parent transid verify failed on 148312850432
w
As tested on Fedora Linux 33 Silverblue, /boot as a btrfs subvol cannot boot at
all. While using Fedora-Silverblue-ostree-x86_64-34-20210405.n.0.iso, (using
Advanced Storage), /boot created as a 2GiB btrfs partition can boot without
issues.
___
test
On Fri, Apr 2, 2021 at 3:50 AM TheEvilSkeleton
wrote:
>
> I tried using /boot on btrfs a couple of times some days ago, and it kept
> failing each time until I used ext4.
>
> This is bad UX. If I need to "fiddle with enough" on a problem that wasn't
> suppo
On Fri, Apr 2, 2021 at 3:42 AM TheEvilSkeleton
wrote:
>
> A couple of days ago I tried to manually install Fedora 34 Silverblue on UEFI
> system and it kept failing when I was using /boot on btrfs. When I switched
> to ext4, it installed flawlessly. I will try it soon on the IS
On Thu, Apr 1, 2021 at 11:18 AM Proprietary Chrome-chan <
theevilskele...@fedoraproject.org> wrote:
> Hi,
>
> `/boot` can be used on btrfs. However, Anaconda forces me to use ext4 in
> that specific, when it shouldn't if you use btrfs.
>
> I'd like to request al
I tried using /boot on btrfs a couple of times some days ago, and it kept
failing each time until I used ext4.
This is bad UX. If I need to "fiddle with enough" on a problem that wasn't
supposed to be a problem, it should be addressed.
By default, when using the automatic
A couple of days ago I tried to manually install Fedora 34 Silverblue on UEFI
system and it kept failing when I was using /boot on btrfs. When I switched to
ext4, it installed flawlessly. I will try it soon on the ISO you linked and
will report back if this issue persists or not.
On April 1
On Thu, Apr 1, 2021 at 10:18 AM Proprietary Chrome-chan
wrote:
>
> Hi,
>
> `/boot` can be used on btrfs. However, Anaconda forces me to use ext4 in that
> specific, when it shouldn't if you use btrfs.
>
> I'd like to request allowing `/boot` to be used on bt
Anaconda do not complain about /boot partition using btrfs, as tested with
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-34-20210401.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-34-20210401.n.0.iso
Testing steps:
1. Boot the USB
2. Choose Custom Storager
3
Hi,
`/boot` can be used on btrfs. However, Anaconda forces me to use ext4 in that
specific, when it shouldn't if you use btrfs.
I'd like to request allowing `/boot` to be used on btrfs.
___
test mailing list -- test@lists.fedoraproj
tors
/dev/sda8 436217856 3907029167 3470811312 1.6T 83 Linux
sda8 is 1777055391744 bytes
Btrfs says:
dev_item.total_bytes 1777055391744
Those agree. The scrub message comes from
block/blk-core.c:655: pr_info_ratelimited("attempt to access beyond
end of device\n"
I don't k
Chris,
No message appeared but the message came out at the beginning of btrfs-convert.
I could convert again if that would help.
dmesg for "this" boot enclosed:
Regards,
George...
On Saturday, March 6, 2021, 1:36:13 PM PST, Chris Murphy
wrote:
fdisk says:
Disk /dev/sda
6, 2021, 1:36:13 PM PST, Chris Murphy
wrote:
fdisk says:
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
/dev/sda8 436217856 3907029167 3470811312 1.6T 83 Linux
sda8 is 1777055391744 bytes
Btrfs says:
dev_item.total_bytes 1777055391744
Those agree. The scrub mes
fdisk says:
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
/dev/sda8 436217856 3907029167 3470811312 1.6T 83 Linux
sda8 is 1777055391744 bytes
Btrfs says:
dev_item.total_bytes1777055391744
Those agree. The scrub message comes from
block/blk-core.c:655
On Sat, Mar 6, 2021 at 1:53 PM George R Goffe wrote:
>
> [17325.282263] BTRFS warning (device sdb1): checksum error at logical
> 498744950784 on dev /dev/sdb1, physical 1415872512, root 256, inode 257,
> offset 262144, length 4096, links 1 (path: image)
> [17325.282299] BTRFS err
fc35-bash 5.1 ~# btrfs inspect-internal dump-super /dev/sda8 | grep bytes
total_bytes 1777055391744
bytes_used 1771772448768
dev_item.total_bytes 1777055391744
dev_item.bytes_used 1777053872128
fc35-bash 5.1 ~# btrfs inspect-internal dump-super /dev/sdb1 | grep
Also need:
sudo btrfs insp dump-s /dev/sda8 | grep 'total_bytes\|dev_item.total_bytes'
sudo btrfs insp dump-s /dev/sdb1 | grep 'total_bytes\|dev_item.total_bytes'
--
Chris
___
test mailing list -- test@lists.fedoraproject.org
To
have nowhere near
> enough extra space to hold the image and tar file you've asked for AND,
> there's too much personal information for me for me to feel comfortable
> posting it publicly.
Understood. e2image doesn't have a filename scrubber like the
btrfs-image equivalen
formation for me for me to feel comfortable
> posting it publicly.
Understood. e2image doesn't have a filename scrubber like the
btrfs-image equivalent (-s and -ss). I don't have a good work around
for this, and suggest asking on the ext4 development list.
> I'm converting a s
tive capacity" by
the way. Is this a problem?
Regards,
George...
On Friday, March 5, 2021, 3:51:14 PM PST, Chris Murphy
wrote:
On Fri, Mar 5, 2021 at 10:39 AM Chris Murphy wrote:
>
> Quick follow up on one thing I can't reproduce from George's scrub:
>
> [3
On Fri, Mar 5, 2021 at 10:39 AM Chris Murphy wrote:
>
> Quick follow up on one thing I can't reproduce from George's scrub:
>
> [36365.549230] BTRFS error (device sda8): scrub: tree block
> 1777055424512 spanning stripes, ignored. logical=1777055367168
> [36365.5492
Quick follow up on one thing I can't reproduce from George's scrub:
[36365.549230] BTRFS error (device sda8): scrub: tree block
1777055424512 spanning stripes, ignored. logical=1777055367168
[36365.549262] attempt to access beyond end of device
sda8: rw=0, want=3470811
On 3/4/21 6:50 AM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
There are a few different types of full-disk backup, but if it's
file-based and the atimes are modified, that's the intent of the
backup process. The atimes are used to determine which files to
On Thu, Mar 4, 2021 at 9:50 AM Matthew Miller wrote:
>
> On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
> > There are a few different types of full-disk backup, but if it's
> > file-based and the atimes are modified, that's the intent of the
> > backup process. The atimes are used t
On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
> There are a few different types of full-disk backup, but if it's
> file-based and the atimes are modified, that's the intent of the
> backup process. The atimes are used to determine which files to
> backup. A scrub is not a backup an
George,
You've found a bug. I've got a reproducer.
https://github.com/kdave/btrfs-progs/issues/349
Both the ext4 rollback file, ext2_saved/image, and the converted btrfs
file system are OK. The corruption is bogus, so the bug is that
somehow checksums on a handful of specific blocks (
a mismatch, right?
If there's a mismatch, and no redundancy, there's no fixup. Therefore no write.
If there's a mismatch, and there's redundancy of some kind, a fixup is
possible. That involves finding the good copy and overwriting the bad.
But this too is at a block level,
On 3/3/21 4:34 PM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote:
It depends on how the scrubbing works. I would have expected it to
be reading data at the filesystem level, not actually opening and
reading every file. That seems like a really bad thing to m
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote:
> It depends on how the scrubbing works. I would have expected it to
> be reading data at the filesystem level, not actually opening and
> reading every file. That seems like a really bad thing to me,
> resetting the atimes on every fil
On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote:
> It works at the block level. A block is read, checksum calculated and
> compared to the previously recorded checksum for the block. It doesn't
> know what it's reading, not even whether it's compressed or not. It
> just becomes a strea
then how it figures out where the good copy is
(if any) and does self-healing. It pretty much runs at device max read
capability.
Related:
'btrfs replace' command utilizes this scrub facility to live replace a
drive, and is the preferred way to replace; as compared to 'btrfs
device ad
keep your backups fresh, while you have the chance.
What I can tell you is Btrfs isn't changing the data or the checksums
on disk. They've changed since the checksums were computed at
btrfs-convert time. While it is possible there's a bug that can
explain this, it's not one I'
On 3/3/21 10:05 AM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
From what I can tell scrubbing only reads data and compares to the stored
checksum. Why would that wear out a SSD?
If you have atimes enabled, reading a file also makes a metadata write. Bu
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
> From what I can tell scrubbing only reads data and compares to the stored
> checksum. Why would that wear out a SSD?
If you have atimes enabled, reading a file also makes a metadata write. But
I don't think it's that big a deal on mod
On Tue, Feb 23, 2021 at 3:26 PM pmkel...@frontier.com
wrote:
> I recall a long and detailed discussion on this list before F33 was
> released concerning what disk maintenance would be required with BTRFS.
> As I recall, the final word was along the lines the running Scrub and
> the
Chris,
Here's the information you requested.
I'm wondering just how this happened. One of the messages refers to "beyond end
of device". I'm alarmed.
Regards,
George...
[ 2017.474378] BTRFS info (device sda8): scrub: started on devid 1
[ 2101.646773] BTRFS warnin
On 2/26/21 14:53, pmkel...@frontier.com wrote:
On 2/25/21 15:24, Chris Murphy wrote:
An alternative is 'btrfs scrub start -BdR' which will not background
the scrub, and will give a detailed report upon completion.
Well I think tried all the combinations of scrub status with a
On Fri, Feb 26, 2021 at 12:53 PM pmkel...@frontier.com
wrote:
>
>
>
> On 2/25/21 15:24, Chris Murphy wrote:
> >
> > An alternative is 'btrfs scrub start -BdR' which will not background
> > the scrub, and will give a detailed report upon completion.
> &g
On 2/25/21 15:24, Chris Murphy wrote:
An alternative is 'btrfs scrub start -BdR' which will not background
the scrub, and will give a detailed report upon completion.
Well I think tried all the combinations of scrub status with and without
-B, -BdR, -dR to try and get status
On Thu, Feb 25, 2021 at 7:25 AM pmkel...@frontier.com
wrote:
> Out of curiosity I ran scrub on the four machines I have handy here. I
> always do clean installs so the btrfs doesn't have a lot of time on it;
> just since F33 was released.
Scrub is pretty performant regardless of f
On Thu, Feb 25, 2021 at 09:25:04AM -0500, pmkel...@frontier.com wrote:
> Scrub gives no indication that it's running other than the PID. Nor
> does it indicate when it's complete; so I had to monitor the PID to
> know when it was done. Then I had to run:
>
> sudo bt
On 2/24/21 20:48, Chris Murphy wrote:
On Tue, Feb 23, 2021 at 2:26 PM pmkel...@frontier.com
wrote:
I recall a long and detailed discussion on this list before F33 was
released concerning what disk maintenance would be required with BTRFS.
As I recall, the final word was along the lines the
On Tue, Feb 23, 2021 at 2:26 PM pmkel...@frontier.com
wrote:
>
> I recall a long and detailed discussion on this list before F33 was
> released concerning what disk maintenance would be required with BTRFS.
> As I recall, the final word was along the lines the running Scrub and
>
On 2/23/21 10:58, Matthew Miller wrote:
On Tue, Feb 23, 2021 at 10:18:13AM -0500, Neal Gompa wrote:
sudo btrfs scrub start /mnt
It's kind of unfortunate that we also have a command (in the distro since
2007) called just "scrub" which will destroy al of your data. :-/
Not g
On Tue, Feb 23, 2021 at 10:18:13AM -0500, Neal Gompa wrote:
> > > sudo btrfs scrub start /mnt
> > It's kind of unfortunate that we also have a command (in the distro since
> > 2007) called just "scrub" which will destroy al of your data. :-/
>
> Not goin
On Tue, Feb 23, 2021 at 10:03 AM Matthew Miller
wrote:
>
> On Mon, Feb 22, 2021 at 02:58:00PM -0700, Chris Murphy wrote:
> > We should find out if there's more widespread corruption. The basic
> > command to scrub that particular Btrfs file system is:
> >
> > s
On Mon, Feb 22, 2021 at 02:58:00PM -0700, Chris Murphy wrote:
> We should find out if there's more widespread corruption. The basic
> command to scrub that particular Btrfs file system is:
>
> sudo btrfs scrub start /mnt
It's kind of unfortunate that we also have a comman
On Mon, Feb 22, 2021 at 1:39 AM George R Goffe wrote:
> Feb 21 18:55:38 fc35 kernel: BTRFS warning (device sda8): csum failed root
> 256 ino 257 off 0 csum 0xe05b8b2e expected csum 0xc90f1f63 mirror 1
> Feb 21 18:55:38 fc35 kernel: BTRFS error (device sda8): bdev /dev/sda8 errs:
>
lems either... hence the alarm.
Regards,
George...
from file command on /export/home/ext2_saved/image:
Feb 21 18:50:29 fc35 kernel: BTRFS warning (device sda8): csum failed root 256
ino 257 off 0 csum 0xe05b8b2e expected csum 0xc90f1f63 mirror 1
Feb 21 18:50:29 fc35 kernel: BTRFS error (dev
On Sun, Feb 21, 2021 at 4:16 PM George R Goffe wrote:
>> On Sunday, February 21, 2021, 1:48:52 PM PST, Chris Murphy
>> wrote:
> That works for me. But you could alternatively try:
>
> mount /dev/vdb /mnt/btrfs
> losetup -r /dev/loop0 /mnt/btrfs/ext2_saved/
a VM. It should work.
Works for me. But I'm confused by your paths, i.e. are you really
creating /ext2_saved and /ext4 in the root directory?
Assume root user:
mount /dev/vdb /mnt/btrfs
# on this system here vdb is sda8. /mnt/btrfs is /export/home
mount -t ext4 -o ro,loop /mnt/btrfs/ex
On Sun, Feb 21, 2021 at 2:21 PM Samuel Sieb wrote:
> > fc35-bash 5.1 ~# mount -t ext4 -o loop,ro /ext2_saved/image /ext4
> > mount: /ext4: can't read superblock on /dev/loop0.
>
> I don't know much about btrfs, but what does "file /ext2_saved/image" say?
Go
Chris,
Thanks for responding.
I'm pretty sure it was after conversion.
George...
On Sunday, February 21, 2021, 1:27:12 PM PST, Chris Murphy
wrote:
On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
wrote:
>
> Hi,
>
> I have converted a large ext4 filesyste
m. That's unexpected though. I'm going to try it in a VM. It should work.
Works for me. But I'm confused by your paths, i.e. are you really
creating /ext2_saved and /ext4 in the root directory?
Assume root user:
mount /dev/vdb /mnt/btrfs
mount -t ext4 -o ro,loop /mnt/btrfs/ext2_sa
On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
wrote:
>
> fc35-bash 5.1 ~# mount -t ext4 -o loop,ro /ext2_saved/image /ext4
> mount: /ext4: can't read superblock on /dev/loop0.
Hmm. That's unexpected though. I'm going to try it in a VM. It should work.
--
Chris Murphy
___
On Sun, Feb 21, 2021 at 2:16 PM George R Goffe via test
wrote:
>
> Hi,
>
> I have converted a large ext4 filesystem to btrfs and by accident deleted an
> important users home directory. Reading btrfs doc seems to imply that the
> directory can be recovered without reverting
On 2/21/21 1:15 PM, George R Goffe via test wrote:
I have converted a large ext4 filesystem to btrfs and by accident deleted an
important users home directory. Reading btrfs doc seems to imply that the
directory can be recovered without reverting the filesystem to ext4.
First, you should
Hi,
I have converted a large ext4 filesystem to btrfs and by accident deleted an
important users home directory. Reading btrfs doc seems to imply that the
directory can be recovered without reverting the filesystem to ext4.
What I've read seems to be telling me to mount the subv
On Tue, Oct 13, 2020 at 7:38 PM Chris Murphy wrote:
>
> Hi,
>
> I'm looking for testers:
> - Fedora 33
> - User home is on Btrfs (clean installed or converted, in a subvolume
> or not, these details won't matter)
> - using any spin other than Workstation (kde, l
On Tue, Oct 13, 2020 at 9:38 PM Chris Murphy wrote:
>
> Hi,
>
> I'm looking for testers:
> - Fedora 33
> - User home is on Btrfs (clean installed or converted, in a subvolume
> or not, these details won't matter)
> - using any spin other than Workstation (kde, l
On Tue, Oct 13, 2020 at 7:38 PM Chris Murphy wrote:
>
> Note 2: It's decently likely you will get the expected results if
> /home is on XFS. Arguably if we get a result on Btrfs indicating
I got distracted, and didn't finish the thought before clicking send!
If the resu
Hi,
I'm looking for testers:
- Fedora 33
- User home is on Btrfs (clean installed or converted, in a subvolume
or not, these details won't matter)
- using any spin other than Workstation (kde, lxqt, xfce, etc are all
requested). I'd like to know which desktops do/don't a
On Sun, Sep 20, 2020 at 2:00 PM George R Goffe via test
wrote:
>
> Hi,
>
> I have 2 VMs with ALL btrfs file systems AND a native (host) /opt of type
> btrfs. I'm playing with compression in one of the VMs...
>
> I have run, in a VM, btrfs-convert and the other commands
Hi,
I have 2 VMs with ALL btrfs file systems AND a native (host) /opt of type
btrfs. I'm playing with compression in one of the VMs...
I have run, in a VM, btrfs-convert and the other commands recommended by the
man page for this command. It all looks good.
It's not clear just what
On Mon, Sep 7, 2020 at 10:14 AM George R Goffe wrote:
>
> Chris,
>
> Thank you for your help.
>
> I had to re-create the initramfs as well and, change fstab too. The process
> was up hill in both directions... due to my fumbling. Sigh.
>
> I now have a VM FC34 x86_64 (
Chris,
Thank you for your help.
I had to re-create the initramfs as well and, change fstab too. The process was
up hill in both directions... due to my fumbling. Sigh.
I now have a VM FC34 x86_64 (Rawhide) running with btrfs file systems.
After a few upgrades I did an "init 0" co
On Wed, Sep 2, 2020 at 3:42 PM George R Goffe via test
wrote:
>
> Hi,
>
> I'm playing around with FC34 ina VM and have backed up /boot; put a btrfs fs
> on the partition; restored from the backup, updated fstab but grub2 still
> goes into rescue mode. This tells me t
Hi,
I'm playing around with FC34 ina VM and have backed up /boot; put a btrfs fs on
the partition; restored from the backup, updated fstab but grub2 still goes
into rescue mode. This tells me that there's something I don't know which is
entirely possible. Could it be a missin
Hey All,
A new change proposal has been submitted for the Fedora 33 release
cycle which entails the usage of Btrfs by default [0] for Workstations and
Spins across x86_64 and ARM architectures, As a result, we have
organized a test week from Monday, Aug 31, 2020. As a part of this test
week, we
uld probably make this a Test Case. And discuss making
> it a release blocking criterion, as it's a significant feature. We've
> always had this capability with LVM+ext4 because /home was a separate
> file system that you can just reuse. And the steps are pretty much the
> same
On Mon, 2020-08-24 at 13:12 -0600, Chris Murphy wrote:
> 1. Create /boot/efi or BIOS Boot mount point (can be reused or
> reformatted)
> 2. Create /boot mount point (can be reused or reformatted)
> 3. Create / mount point (this is required to be a new subvolume)
Ah. Ok, this is the point. I was tr
On 8/24/20 3:25 PM, Chris Murphy wrote:
On Mon, Aug 24, 2020 at 1:18 PM Brandon Nielsen wrote:
[Snip]
Is the "I would like to make additional space available" checkbox going
to grow subvolume support? Right now your only option is to blow away
the entire btrfs volume from
> 5. Click on that subvolume, and on the right hand side at the top,
> > find Mount Point field; type in /home; click Update Settings button.
> > 6. Click Done
> >
> > This is a rough draft :) I'm going by memory.
> >
>
> Is the "I would like to make a
w subvolume support? Right now your only option is to blow away
the entire btrfs volume from a previous install.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Condu
.
> 6. Click Done
>
> This is a rough draft :) I'm going by memory.
In fact, we should probably make this a Test Case. And discuss making
it a release blocking criterion, as it's a significant feature. We've
always had this capability with LVM+ext4 because
On Mon, Aug 24, 2020 at 4:40 AM Alessio wrote:
>
> Hello.
> I was performing some random test of F33.
> There is a thing that I can't understand.
> If I reinstall the system on an disk where I already installed Fedora
> 33 before, and I want to preserve the content of the home subvolume, is
> this
Hello.
I was performing some random test of F33.
There is a thing that I can't understand.
If I reinstall the system on an disk where I already installed Fedora
33 before, and I want to preserve the content of the home subvolume, is
this feasible? I tried various things using Anaconda, but I'm stil
On Thu, Aug 13, 2020 at 9:30 AM George R Goffe via test
wrote:
>
> Hi,
>
> I was reading about filesystems in Linux, specifically RedHat systems, and
> there was a lot about btrfs and how good it is.
>
> With this in mind, I tried to install my favorite Fedora Core syst
Hello George,
BTRFS is definitely supported by Anaconda. I installed Fedora 33
Silverblue Rawhide onto BTRFS. I believe the installer uses a default
layout if you choose the btrfs option with automatic partition layout.
Of course I haven't tried a VM of it.
F32 (current stable release) is ab
Hi,
I was reading about filesystems in Linux, specifically RedHat systems, and
there was a lot about btrfs and how good it is.
With this in mind, I tried to install my favorite Fedora Core system (Currently
FC33) uner QEMU, but saw in the custom partitioning part of the dialogues that
btrfs
On 7/20/20 21:34, Michel Alexandre Salim wrote:
That's a misleading log message; see e.g. this discussion
https://bbs.archlinux.org/viewtopic.php?id=231884
You probably want to use this to check the actual RAID level.
btrfs filesystem df /
source:
https://btrfs.wiki.kernel.org/inde
On Tue, 2020-07-07 at 14:38 -0400, pmkel...@frontier.com wrote:
>
> Also, I don't understand why this is raid6 There is only one disk in
> my
> test machine. Also I did nothing in the btrfs settings to call for a
> raid. I just took the btrfs defaults.
>
That's a
On Sat, Jul 11, 2020 at 7:19 PM Chris Murphy
wrote:
> I think the test case just needs to be enhanced with a better grep to
> exclude the raid6 module's message; while still including FAT, XFS,
> ext4, and adding the new Btrfs treelog message. I'm not good enough
> with
In attempting to test the latest nominated compose, I encountered issues
attempting to do a guided reclaim of space from a btrfs partition
created by the btrfs test day compose.
I submitted a bug report[0] and can try getting more information if
someone has ideas for what would be most
f this is a problem or if we need to update the testcase for
> >>> btrfs. I've attached the journal file for your reading pleasure.
> >
> > This is a good point. The testcase needs two updates. The one
> > previously mentioned which is not an fs journal recover
On 7/9/20 10:31, Chris Murphy wrote:
On Tue, Jul 7, 2020 at 5:46 PM pmkel...@frontier.com
wrote:
However as I look at the journal it's not
clear if this is a problem or if we need to update the testcase for
btrfs. I've attached the journal file for your reading pleasure.
This
On Tue, Jul 7, 2020 at 5:46 PM pmkel...@frontier.com
wrote:
> However as I look at the journal it's not
> > clear if this is a problem or if we need to update the testcase for
> > btrfs. I've attached the journal file for your reading pleasure.
This is a good poin
On Tue, Jul 7, 2020 at 5:46 PM pmkel...@frontier.com
wrote:
>
> I have been testing btrfs in a fresh install of Rawhide 0703 WS. I've
> mostly been doing my home grown "as deployed testing". So far the only
> potential maybe problem I can see is when I do the
> (QA:T
On Wed, Jul 8, 2020 at 12:55 AM Sumantro Mukherjee
wrote:
> Hey All,
>
> A new change proposal has been submitted for the Fedora 33 release
> cycle which entails usage of btrfs by default [0] for Workstations and
> Spins across x86_64 and ARM architectures As a result, we hav
Hey All,
A new change proposal has been submitted for the Fedora 33 release
cycle which entails usage of btrfs by default [0] for Workstations and
Spins across x86_64 and ARM architectures As a result, we have
organized a test day on Wed, July 08, 2020. As a part of this test
day, we will aim at
provide a checkbox
for deleting all related partitions. Check that, then click "OK". It
should clear them out. If there's any more you want to delete, rinse
and repeat.
Then you can use the drop down menu to select Btrfs and have it create
the layout as you attempted before.
Thank y
On Mon, Jul 6, 2020 at 7:43 PM pmkel...@frontier.com
wrote:
>
>
> After the QA meeting today, I spent a few hours trying the get Rawhide
> 0703 WS Live installed with btrfs.
>
> I have Rawhide 0703 WS Live on a thumb drive. I know this works fine
> when taking the defaul
1 - 100 of 267 matches
Mail list logo
