Am 04.05.2014 20:40, schrieb J. Roeleveld:
> On Sunday, May 04, 2014 03:07:28 PM Stefan G. Weichinger wrote:

>> Oh, yes, I like ZFS and its features and used it in some cases already.
>> But I didn't yet take the step to set up ZFS-root on my work machines.
> 
> I haven't yet, but it's on the list of items to look into at some point.
> I'd like to know if, with ZFS, it is possible to create block-devices like 
> LVs 
> which I can then attach to VMs. Or if I have to use files instead.

I think you would have to use files on top of ZFS ... but I am not
up-to-date in that area.

People run KVM-hosts with storage on ZFS ... nice with the snapshots etc ...

> I think it does as I get the following on my server:
> ***
> # gdisk -l /dev/sda
> GPT fdisk (gdisk) version 0.8.8
> 
> Partition table scan:
>   MBR: protective
>   BSD: not present
>   APM: not present
>   GPT: present
> 
> Found valid GPT with protective MBR; using GPT.
> Disk /dev/sda: 11718749184 sectors, 5.5 TiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): 936FDBE4-A736-41CF-B9A5-51069940D3DB
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 11718749150
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 2014 sectors (1007.0 KiB)
> 
> Number  Start (sector)    End (sector)  Size       Code  Name
>    1            2048          411647   200.0 MiB   EF00  EFI System
>    2          411648         2101247   825.0 MiB   8300  Linux filesystem
>    3         2101248     11718749150   5.5 TiB     8E00  Linux LVM
> 
> ***
> 
> That's a hardware raid device with 4 * 3TB disks with raid-6.
> I don't like the fact that a 2nd disk-failure can kill a raid-10 when both 
> disks are in the same mirror-set.
> 
> gdisk automatically aligns on 2048 sector boundaries, that is more then 
> enough 
> for the 4k-sectors and the block/stripe sizes employed by the raid-controller.

Yes, this is for UEFI booting, thanks.

I tried to migrate to GPT/BIOS-booting today but failed. It seems my
mainboard/BIOS has problems detecting that ... I vaguely remember this
from trying it back then.

So I am back on a freshly partitioned and formatted SSD with plain old
MBR now.

I also wanted to partition the SSD according to the Erase Block Size of
6144 kB by this way ... dunno if this is still needed or has any real
speed benefits.

Maybe I take another approach to migrate to UEFI/GPT in the next days,
now that I have my rsynced filesystems at hand (I got rid of more LVs
and stuff so it gets pretty slim now).


> UUIDs, I believe, do work natively. And those are stored inside the partition 
> itself. Which means they should also work. But are not as easy to locate. 
> (eg. 
> you don't specify them yourself)

Yep. LABELs are human readable ... big advantage.

> See the partitioning on my server above.
> It boots using BIOS as I haven't been able to boot Xen using UEFI yet.

So then the EFI partition is useless ...

> Support should be there now, but not been able to test that yet.
> GPT is supported by grub-1 (and grub2) and with the MBR-support inside GPT, 
> booting works from BIOS/MBR.

... if your BIOS isn't crappy ;-)

S

Reply via email to