Re: Fedora 15, new and exciting plans

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Return to GRUB2 topic, I wish that GRUB2 landed in Anaconda and become an option for user. Some Linux fans install two Linux distros, one is rpm-based distro, another is deb-based distro. Most of deb-based distros has moved to GRUB2. however, rpm-based distros still stays at GRUB legacy. I can feel there are some problems on compatibility. 

Does anyone know something about GRUB2 on mapper devices? Half a year ago, I tried to install Debian on my Intel RAID0 but failed. At that time, Debian installer does not support that users directly install GRUB2. You need extra steps to do it manually. I think  the maintainers should consider it and find out the best solution for users.

The other topic is about Xen. As we know, Xen Dom0 pv_ops are merged into the upstream kernel since 2.6.37. Fedora 15 will use kernel-2.6.38. Should community bring Xen Dom0 to Fedora 15 since Fedora 8 though Red Hat does no longer support Xen? Because Xen Dom0 pv_ops is a part of upstream kernel, Debian has a plan to drop specified kernel for Xen and directly support it in generic kernel. Does Fedora has some plans to do it? I know Xen is still maintained by myong in Fedora.  

On Sun, Nov 14, 2010 at 10:23 AM, Dennis Jacobfeuerborn <dennisml@xxxxxxxxxxxx> wrote:
On 11/14/2010 12:41 AM, Richard W.M. Jones wrote:
> On Fri, Nov 12, 2010 at 06:26:48PM +0000, "Jóhann B. Guðmundsson" wrote:
>> *DE could consider switching the default to use EXT4 directly without
>> LVM. [1]
>> 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM
>
> The "Detailed Description" seems contradictory:
>
> | LVM provides very little benefit for most Fedora users, at the cost of
> | performance and complexity:
> |
> | * Certain filesystem features (ext3 barriers) are unavailable when run
> |   on top of LVM.
>
> Isn't this just a bug which should be fixed?  (I actually thought this
> had been fixed already)
>
> | * Software RAID performance is greatly reduced when layered on LVM.
>
> But the stated task is to get rid of LVM except for "experts in
> storage administration" (from the next section of the same document).
> Who will presumably be the only ones wanting Software RAID.  The
> non-experts won't know anything about Software RAID, so they won't be
> affected by this performance problem with LVM.

Can someone point to specific details about this? I did some benchmarking a
while ago of raid-1 vs. raid-5, raid-1 plain vs. raid-1 with lvm, etc. and
LVM didn't really show up as a performance issue at all.

> | * LVM partitions are not automatically assembled by the desktop systems.
>
> I'm not sure what this one means.  "assembled" as in what happens when
> you spread a VG over multiple block devices?
>
> Anyway, I think LVM is jolly useful:

I've used plain partitions for a long time because lvm always looked weird
to me but then I looked into it and nowadays I don't want to live without
it. The ability to have the logical partitioning indepedent of the physical
storage is a must-have for me.

> - You can expand the root filesystem (eg. into spare space or
> across block devices).
>
> - You can live pvmove filesystems from one device to another.

That one actually saved my ass once on a 48 disk 30TB storage system
because the controller was acting up.

> It may be that the tooling is not there to make these features
> available for non-experts, but that's a problem with lack of tools,
> not with LVM.  Partition tables are horrible and inflexible in
> comparison to LVM.
>
> Can we at the very least have some numbers backing up the supposed
> performance problems?

Yeah, in my benchmarking I couldn't really confirm this so if there is a
problem I'd like to see some specifics too.

Regards,
  Dennis



--
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux