GNU GRUB - Bugs: bug #32931, LVM write support, patch included
You are not allowed to post comments on this tracker with your current authentication level.
bug #32931: LVM write support, patch included
Submitter: | Valentin Hilbig <tino> | ||
Submitted: | Sun 27 Mar 2011 10:16:44 PM UTC | ||
Category: | Disk & Partition | Severity: | Major |
Priority: | 5 - Normal | Item Group: | Feature Request |
Status: | Wont Fix | Privacy: | Public |
Assigned to: | None | Originator Name: | |
Open/Closed: | Closed | Release: | 1.98 |
Release: | Reproducibility: | Every Time | |
Planned Release: | None |
Wed 30 Mar 2011 08:01:23 PM UTC, comment #3: |
Vladimir Serbinenko <phcoder> |
Mon 28 Mar 2011 12:08:37 AM UTC, comment #2: Thanks, good point, I missed that completely.
|
Valentin Hilbig <tino> |
Sun 27 Mar 2011 10:30:17 PM UTC, comment #1: I suppose that you didn't follow the discussion on LVM writing. Basically the problem is safety: any bug in LVM writing code would result in disk corruption. Your patch actually perfectly illustrates one of the points which were discussed: in case of multiple copies (e.g. stripped LVM) only one is needed for read but you need to update all of them when you write. Your patch will surely corrupt any mirrored LVM. I recommend to discuss the approach on -email is unavailable- before proceding. |
Vladimir Serbinenko <phcoder> |
Sun 27 Mar 2011 10:16:44 PM UTC, original submission:
Here is a patch for grub_lvm_write() based on grub_lvm_read() to add write support on LVM. This makes save_env and GRUB_DEFAULT=saved work as expected for LVM volumes on GNU/Linux, too.
|
Valentin Hilbig <tino> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-03-30 | phcoder | Status | None | Wont Fix | |
Open/Closed | Open | Closed | |||
2011-03-28 | tino | Attached File | - | Added lvm-write.2.patch, #23033 | |
2011-03-27 | tino | Attached File | - | Added lvm-write.patch, #23031 |
Powered by Savane 3.13-f8d8.
Corresponding source code
Allowing only when user specifically selects so sounds good in theory, in practice, though, people will just force it without thinking of consequences on their system. Also LVM would try to repair itself and so will conflict with GRUB. If nothing else, if it stays non-official it clearly says that it can damage the data.
There is a difference between considering something low-quality and actively damaging it. I've tested LVM mirror only once for testing GRUB in such conditions so I can't say anything about its quality. But even without lvm mirror, if you have snapshots then probably some blocks are shared and writing to them will change the data in snapshots as well.
The LVM write is a no-go unless a strategy is proposed which will avoid corrupting data no matter what (this would need to be discussed at grub-devel@gnu.org)
The consensus reached in last LVM discussion was to use embedding zone. Same consensus was reached for other similar situations: mdraid, zfs and btrfs.
It would be desirable to ask LVM maintainers to allow us to use some space for such things. E.g. we could use the space after the last usable block. It would be helpful if one could tell to have at least e.g. 64K there. This would need a small revival discussion at grub-devel@gnu.org. None of this was done yet.
Since LVM write probably will never be accepted, marking it as wontfix. For embedding area please discuss upstream.