btrfs trim erases bootloader area
As discussed on opensuse-factory list, running fstrim on btrfs erases bootloader area, rendering system unbootable. See
https://lists.opensuse.org/opensuse-factory/2016-01/msg00067.html
https://lists.opensuse.org/opensuse-factory/2016-01/msg00090.html
and follow-ups that demonstrate that beginning of device gets zeroed out.
Not sure what we can do, but from GRUB side I can only see disabling embedding support on btrfs entirely.
Quoted 10 lines · Andrei Borzenkov
As discussed on opensuse-factory list, running fstrim on btrfs erases bootloader area, rendering system unbootable. See
https://lists.opensuse.org/opensuse-factory/2016-01/msg00067.html
https://lists.opensuse.org/opensuse-factory/2016-01/msg00090.htmland follow-ups that demonstrate that beginning of device gets zeroed out.
Not sure what we can do, but from GRUB side I can only see disabling embedding support on btrfs entirely.
Try this (sent to the btrfs mailing list yesterday):
thanks
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Quoted 10 lines · Andrei Borzenkov
As discussed on opensuse-factory list, running fstrim on btrfs erases bootloader area, rendering system unbootable. See
https://lists.opensuse.org/opensuse-factory/2016-01/msg00067.html
https://lists.opensuse.org/opensuse-factory/2016-01/msg00090.htmland follow-ups that demonstrate that beginning of device gets zeroed out.
Not sure what we can do, but from GRUB side I can only see disabling embedding support on btrfs entirely.
Since you're probably not on the btrfs list and missed it earlier
today: http://www.spinics.net/lists/linux-btrfs/msg50860.html
-h
Quoted 9 lines · Filipe Manana
Quoted 8 lines · Andrei Borzenkov
As discussed on opensuse-factory list, running fstrim on btrfs erases bootloader area, rendering system unbootable. See
https://lists.opensuse.org/opensuse-factory/2016-01/msg00067.html
https://lists.opensuse.org/opensuse-factory/2016-01/msg00090.htmland follow-ups that demonstrate that beginning of device gets zeroed out.
Quoted 8 lines
Quoted 2 lines
Not sure what we can do, but from GRUB side I can only see disabling embedding support on btrfs entirely.
Try this (sent to the btrfs mailing list yesterday):
thanks
The description is a bit confusing by referring to MBR, which mainly exists only at LBA 0. In the case of extended partitions, the EBR (using the same MBR format) is still outside the LBA range for Btrfs to apply fitrim ioctl. The VBR however, would be inside that range, and it's that 64KiB bootloader pad Btrfs reserves that's being inadvertently obliterated. Correct?
Chris Murphy
Quoted 17 lines · Chris Murphy
Quoted 16 lines · Filipe Manana
Quoted 10 lines · Andrei Borzenkov
As discussed on opensuse-factory list, running fstrim on btrfs erases bootloader area, rendering system unbootable. See
https://lists.opensuse.org/opensuse-factory/2016-01/msg00067.html
https://lists.opensuse.org/opensuse-factory/2016-01/msg00090.htmland follow-ups that demonstrate that beginning of device gets zeroed out.
Not sure what we can do, but from GRUB side I can only see disabling embedding support on btrfs entirely.
Try this (sent to the btrfs mailing list yesterday):
Quoted 8 lines
Quoted 1 line
thanks
The description is a bit confusing by referring to MBR, which mainly exists only at LBA 0. In the case of extended partitions, the EBR (using the same MBR format) is still outside the LBA range for Btrfs to apply fitrim ioctl. The VBR however, would be inside that range, and it's that 64KiB bootloader pad Btrfs reserves that's being inadvertently obliterated. Correct?
Right, the title and description is confusing. I lacked the terminology and all technical details of grub, so I just used MBR to refer to any sector containing code used by the boot loader. Do you like the following title/change log better?
I'll resend it later or tomorrow.
thanks
Quoted 4 lines
Chris Murphy
Signature · 5 lines
Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Quoted 27 lines · Filipe Manana
Quoted 17 lines · Chris Murphy
Quoted 16 lines · Filipe Manana
Quoted 10 lines · Andrei Borzenkov
As discussed on opensuse-factory list, running fstrim on btrfs erases bootloader area, rendering system unbootable. See
https://lists.opensuse.org/opensuse-factory/2016-01/msg00067.html
https://lists.opensuse.org/opensuse-factory/2016-01/msg00090.htmland follow-ups that demonstrate that beginning of device gets zeroed out.
Not sure what we can do, but from GRUB side I can only see disabling embedding support on btrfs entirely.
Try this (sent to the btrfs mailing list yesterday):
Quoted 8 lines
Quoted 1 line
thanks
The description is a bit confusing by referring to MBR, which mainly exists only at LBA 0. In the case of extended partitions, the EBR (using the same MBR format) is still outside the LBA range for Btrfs to apply fitrim ioctl. The VBR however, would be inside that range, and it's that 64KiB bootloader pad Btrfs reserves that's being inadvertently obliterated. Correct?
Quoted 9 lines
Right, the title and description is confusing. I lacked the terminology and all technical details of grub, so I just used MBR to refer to any sector containing code used by the boot loader. Do you like the following title/change log better?
I'll resend it later or tomorrow.
Looks good to me!
Signature · 1 line
Chris Murphy
Hey.
Just a followup on this:
GPT and some others (e.g MD RAID) store data in the end of the device.
It's clear that when the fs is made inside a partition, this shouldn't be seen (and thus TRIMmed) anyway... but can btrfs be installed e.g. directly on the device while that continues to hold the GPT (by btrfs simply always starting at some byte offset)?
If so, then one may possibly need to extend that patch for the end of the device.
Cheers,
Chris.
08.01.2016 04:44, Christoph Anton Mitterer пишет:
Quoted 9 lines
Hey.
Just a followup on this:
GPT and some others (e.g MD RAID) store data in the end of the device.It's clear that when the fs is made inside a partition, this shouldn't be seen (and thus TRIMmed) anyway... but can btrfs be installed e.g. directly on the device while that continues to hold the GPT (by btrfs simply always starting at some byte offset)?
If btrfs size includes metadata at the end of device - arguably it is user error; it should not happen.
If user explicitly excluded metadata (mkfs.btrfs -b <size>) but btrfs still attempts to trim beyond end of filesystem - this is obviously bug and should not happen. I do not understand much of btrfs internals to know if this is possible.
Note that corner case is when filesystem size is not multiple of trim units size. Then incomplete chunks(s) at the beginning and end should always be skipped.
Quoted 6 lines
If so, then one may possibly need to extend that patch for the end of the device.
Cheers,
Chris.