Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= <phcoder <at> gmail.com>
Subject: [RFC, RFT] LDM ("Dynamic disk") support
Newsgroups: gmane.comp.boot-loaders.grub.devel
Date: Sunday 21st August 2011 00:25:01 UTC (over 6 years ago)
Hello, all. I've implemented LDM ("Dynamic disk") support. It allows to
easily have dual-bootable RAIDed volumes.  I've tested only with simple
volumes but it should work with spanned, mirrored and mirrored-spanned
ones but not with stripped or RAID5 (TODO, use separate /boot for now).
I've pushed it to
http://bzr.savannah.gnu.org/lh/grub/branches/ldm/changes.
I've also
successfully installed GRUB to a LDM. For this we need a small (1M)
simple volume on boot disk for embedding similar to what we have on GPT.
In my test I've just manually set it to use "Volume5". This obviously
isn't appropriate for deployement. So we need a way to choose embedding
partition. The ways I see are:
1) Let user specify. While seems to make sense in prectice it would mean
that user choice is stored somewhere and on disk manipulations it may
get out of sync and result in data loss on next install.
2) Use the partition type field. On LDM it's only one byte so it's more
difficult to choose an unique id. But more importantly Windows Disk
Manager tools allow only to choose either type NTFS or FAT and I'm not
aware of any other LDM-editing tools (but would be happy to be wrong
about this) which makes it difficult for end user to mark his embedding
partition.
3) Use a partition with FS which supports embedding. BtrFS and FAT
(specifically formatted with large number of reserved sectors) are
likely candidates and additionally allow to host GRUB files or even an
entire OS. However, it's difficult to check that its embedding zone
isn't in use by some other booting tool since we don't know if we have
ownership of any sense of the partition in question.
4) Use some kind of marker in the partition itself and supply a tool to
set this marker. Seems to be the most attractive choice. But we need to
ensure that this marker is destroyed if partition is formatted in any of
the FS or partitioned with common formats. We could just fill sectors
with string "GRUB". To cover just the FS supported in GRUB we need to
fill following ones:
0 (FAT, NTFS, AFFS, XFS,romfs,SFS,SquashFS,UFS,msdos,gpt,apple,dvh,Sun),
1 (BFS, BSD,sunpc), 2 (AFS, EXT*, HFS, HFS+, minix, nilfs2), 6 (Acorn),
0-15 (amiga), 16 (UFS), 32 (ZFS), 64 (ISO9660, JFS), 128 (BtrFS,
reiserfs, UFS), 256 (UDF), 512 (UDF,UFS), 1024(UDF), 2048 (UDF), 4096
(UDF), 8192 (UDF)
It seems that FS devs like using powers of 2. So to avoid storing this
sequence and future robustness I propose to fill sectors 0-32 (16KiB)
and all powers of 2 until 8192. It results in some need for fragmented
blocklists but it's not too bad.
Also whichever method we choose I also intend to apply it to various bsd
cases as well.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
 
CD: 3ms