Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote: > LVM actually slows down boot considerably. Not primarily because its > code was slow or anything, but simply because it isn't really written in > the way that things are expected to work these days. The LVM assembly at > boot is expected to be run at a time where all disks have been found by > the kernel and identified. However, the idea that such a time exists is > out-of-date on modern systems. There is simply no point in time where > all disks have been enumerated, because they can always come and go and > on many busses (for example USB), you never know whether you have > enumerated all devices, because the bus doesn't support a notion like > that. The right way how to implement a logic like this is to wait > exactly until all disks actually *needed* have shown up and at that time > assemble LVM. Currently, to make LVM work, we however try to wait until > *everything* thinkable is enumerated, not only the disks that are > actually needed. The fact that on many busses this point in time doesn't > really exist is ignored, and awful hacks such as "modprobe > scsi_wait_scan" are used to work around this out-of-date design on the > other busses. To get to a fast system however, you should minimize the > time you waste and continue withthe next step of booting the moment you > have collected all devices you need for assembly. Thanks for explaining what the "assembly" issue is all about. I'd really like to hear from an LVM expert or two about this, because I can't believe that it's impossible to make this work better for the common single-disk-is-boot-disk single-PV case. The LVM metadata (which I've written code to read and decode in the past) contains the information needed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101114 changes
Compose started at Sun Nov 14 08:15:04 UTC 2010 Broken deps for x86_64 -- apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) balsa-2.4.7-2.fc14.x86_64 requires libnotify.so.1()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper edje-0.9.99.49898-1.fc14.i686 requires libecore_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libembryo-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libevas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libembryo-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit) edje-devel-0.9.99.49898-1.fc14.i686 requires pkgconfig(eina-0) edje-devel-0.9.99.49898-1.fc14.x86_64 requires pkgconfig(eina-0) efreet-0.5.0.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) efreet-devel-0.5.0.49898-1.fc14.i686 requires pkgconfig(eina-0) efreet-devel-0.5.0.49898-1.fc14.x86_64 requires pkgconfig(eina-0) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeconnman-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libehal-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libedbus-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libebluez-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeofono-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_x-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_con-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_ipc-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit) enlightenment-devel-0.16.999.49898-1.fc14.i686 requires pkgconfig(eina-0) enlightenment-devel-0.16.999.49898-1.fc14.x86_64 requires pkgconfig(eina-0) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) freefem++-3.9-
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: > On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: > > Greetings. > > > > Fedora 14 was a pretty relaxing and stable release. I'm thinking that > > Fedora 15 may be much more exciting. ;) > > biosdevname installed by default, used in the installer and at runtime > to rename Dell and HP server onboard NICs from non-deterministic > "ethX" to clearly labeled "lomX" matching the chassis silkscreen. But why “lomX” for all? Isn't Lights-Out-Management available only on first ethernet port and often on dedicated port? -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap
Hi packagers, I've a re-review request for hatari: https://bugzilla.redhat.com/show_bug.cgi?id=62 Would anyone want to swap one of their review tickets for this? Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
Hello! 2010/11/14 Andrea Musuruane : > Hi packagers, > I've a re-review request for hatari: > https://bugzilla.redhat.com/show_bug.cgi?id=62 > > Would anyone want to swap one of their review tickets for this? I'll take it. Here is my review request: erlang-rpm-macros - Macros for simplifying building of Erlang packages https://bugzilla.redhat.com/show_bug.cgi?id=652544 -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
On Sun, Nov 14, 2010 at 12:26 PM, Peter Lemenkov wrote: > I'll take it. > Here is my review request: > > erlang-rpm-macros - Macros for simplifying building of Erlang packages > https://bugzilla.redhat.com/show_bug.cgi?id=652544 Perfect. Thanks! Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Le dimanche 14 novembre 2010 à 01:14 +0100, Lennart Poettering a écrit : > Well, there's no doubt that LVM has its uses, but that doesn't mean we > should install it by default on every Fedora installation. > > LVM actually slows down boot considerably. Not primarily because its > code was slow or anything, but simply because it isn't really written in > the way that things are expected to work these days. But wasn"t systemd supposed to fix this kind of problem (dumping things overboard is not fixing) ? LVM may not be very useful on single-hdd laptops, but on desktops it makes adding/changing disks really easy. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
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 < denni...@conversis.de> wrote: > On 11/14/2010 12:41 AM, Richard W.M. Jones wrote: > > On Fri, Nov 12, 2010 at 06:26:48PM +, "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 > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates to static library packages
On Sat, 13 Nov 2010 19:12:18 -0600, Rex Dieter wrote: > Thanks to http://yum.baseurl.org/wiki/RepoQuery > > If you need to figure out which srpms have a buildrequirement on a > particular pkgname run: > repoquery --archlist=src --repoid=some_repo_with_srpms \ > -q --whatrequires pkgname > Aha! Thanks. -- Michel Alexandre Salim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 14/11/10 12:18, Liang Suilong wrote: > 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. > > Have been testing on bare and vm's, have been haing trouble with it. with grub1 you edit /boot/grub/menu.lst to get some tweaks set permanently, or enter on the fly during bootup. with grub2, tested both chainloaded with grub1, and with yum erase grub. Though it found updated kernels', it never booted them unless "grub2-mkconfig -o /boot/grub2/grub.cfg" was run manually. It also requires edits in a number of files, to get permanent tweaks instead of one simple file. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, Nov 13, 2010 at 02:22:42PM +, Matthew Garrett wrote: > On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote: > > > The documented issues do not seem to be as bad as a system being > > exploited. It is only about dependency breakage or services not working > > anymore. There is no major data corruption requiring access to backups > > and restoring the whole system. But this is what people using Fedora > > with proftpd and being exploited have to do. > > If security updates break functionality then people will stop applying > security updates. If there are no security updates, people can not apply them. So what is worse? If people stop applying updates, then it is at least their decision. If there are no updates, people can only choose not to use Fedora. E.g. either build the applications themselves or use another distribution. But this is not a viable goal. The optimal case is to provide well tested security updates fast, but this is not what Fedora achieves. In my example there is no indication that the update was especially tested, because it did not get any karma. And it was not provided fast. Regards Till pgp56Yiarx39Y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Confused with budhi: my package is pushed to stable, but resides in updates-testing!?!
Hi, /*Kevin Fenzi */ wrote on 11/14/2010 2:49:34 AM +0350: On Sat, 13 Nov 2010 20:50:07 +0330 Hedayat Vatankhah wrote: /*Hedayat Vatankhah*/ wrote on 11/13/2010 5:28:49 PM +0350: Hi all, According to [1], my updated simspark package has been pushed to stable; but it is not! The package is available in updates-testing. I wonder if it is expected considering the new updating criteria or it is a bug. Anyway, it is confusing. What's happening? Finally a question: this update is simply a rebuild of the package and I wanted it to reside in updates repository ASAP (For whatever reason, the previous build causes an application using this library to crash; but it is fixed with a rebuild of the packages. I don't know why, but a rebuild fixes the problem.). Thanks, Hedayat Oops, sorry: [1] https://admin.fedoraproject.org/updates/simspark-0.2.1-3.fc14 I think Bodhi got confused by your submission: You submitted the update to testing with a karma of +1 It started going to testing in the next push. You added +1 karma to your own update and it started going to stable. I think we will need to get Luke to look into this after he gets back from vacation. In the mean time I can try unpushing it and repushing it... Shall I do that, or leave it in updates-testing for now? As I've mentioned, this update is a simple rebuild and the current package in stable repositories is simply unusable as it crashes immediately. So, please push it to stable ASAP. Thanks a lot, Hedayat kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, 13 Nov 2010 18:54:02 +, Pierre Carrier wrote: > On Sat, Nov 13, 2010 at 18:01, Nicolas Mailhot > wrote: >> I despair of making *nix input people understand that LANGAGE ≠ INPUT >> Please stop trying to derive one from the other, they are *distinct* >> and one can (and often does) use a non-english layout to type English. >> It's about as smart as trying to find German people in Europe by >> searching for Volkswagen cars. Sometimes it will be right, most often >> it will be terribly wrong. > > Yes, and it has nothing to do with system-wide or even session-wide > settings IMHO. > > I'm a French guy living in GB. > I type on French AZERTY or UK QWERTY hardware layouts, occasionally > German QWERTZ. > My software layout layout is always QWERTY US. I mostly use the Same here. I'm an English-speaker working in Germany, and find it much more convenient to keep my keyboard in US international layout with AltGr dead keys, using the dead keys for entering Umlauts when necessary. The German layout is *horrible* for programming. We have locale for describing language, punctuation marks, etc.; it should have no correlation with keyboard layout. -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM: signing uncompressed data instead of signed data?
On Thu, 11 Nov 2010 10:17:57 -0500, Andre Robatino wrote: > James Antill wrote: > >> IMO, as has been said before, if you have a delta method that doesn't >> produce the exact same bits at the end ... you've probably failed. It >> might seem like a good idea, but even if you go to the extreme lengths >> needed to make it just for yum ... things like reposync won't be able >> to use it, Eg. >> >> http://james.fedorapeople.org/python/delta-rpm-dir.py > > I realize there's a lot of stuff sitting on top of RPM that depends on > how it works currently, but in terms of correctness, it still seems to > me to make more sense to sign the uncompressed data, since that's what > actually gets used, and it would avoid issues like > https://fedorahosted.org/rel-eng/ticket/4224 which will have to be dealt > with periodically as long as compression continues to improve. This is what 0install uses: http://0install.net/faq.html -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 10:11:11PM -0800, John Reiser wrote:
> On 11/13/2010 06:34 PM, Matt Domsch wrote:
> > biosdevname installed by default, used in the installer and at runtime
> > to rename Dell and HP server onboard NICs from non-deterministic
> > "ethX" to clearly labeled "lomX" matching the chassis silkscreen.
> >
> > http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
>
> In that message I see:
> ** No rename for all others "ethX" (no change for NICs in PCI
> slots/USB/others)
>
> I'd like an option to assign "ethX" to NICs in /sys/devices/pci* order.
> This matches chassis PCI slot order on many, many motherboards.
> I get confused when ethX is assigned in a different order.
>
> You can bind ethX to a specific card [not slot] by using HWADDR= in
> /etc/sysconfig/network-scripts/ifcfg-ethX. That's fine, but I prefer
> an option to assign ethX by PCI slot, because that's what I can see when
> I plug in the cables. My NICs are various brands and models,
> but I treat them all as generic because that is much simpler,
> especially in the beginning.
For you, biosdevname has alternate naming policies. You'll edit
/etc/udev/rules.d/71-netdevice.rules, changing --policy=loms to
--policy={something else}, with various choices available:
[loms|kernelnames|all_ethN|all_names|embedded_ethN_slots_names|smbios_names]
all_ethN does exactly what you want, embedded devices first, then all
other devices in ascending PCI slot order.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sun, Nov 14, 2010 at 11:57:59AM +0100, Tomasz Torcz wrote: > On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: > > On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: > > > Greetings. > > > > > > Fedora 14 was a pretty relaxing and stable release. I'm thinking that > > > Fedora 15 may be much more exciting. ;) > > > > biosdevname installed by default, used in the installer and at runtime > > to rename Dell and HP server onboard NICs from non-deterministic > > "ethX" to clearly labeled "lomX" matching the chassis silkscreen. > > But why ???lomX??? for all? Isn't Lights-Out-Management available only on > first > ethernet port and often on dedicated port? This has nothing to do with Lights-Out-Management. LOM also == LAN on Motherboard. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 14.11.10 13:14, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: > Le dimanche 14 novembre 2010 à 01:14 +0100, Lennart Poettering a écrit : > > > Well, there's no doubt that LVM has its uses, but that doesn't mean we > > should install it by default on every Fedora installation. > > > > LVM actually slows down boot considerably. Not primarily because its > > code was slow or anything, but simply because it isn't really written in > > the way that things are expected to work these days. > > But wasn"t systemd supposed to fix this kind of problem (dumping things > overboard is not fixing) ? LVM may not be very useful on single-hdd > laptops, but on desktops it makes adding/changing disks really easy. systemd is definitely not going into the realms of storage assembly. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sun, Nov 14, 2010 at 13:59:24 +0100, Till Maas wrote: > > If there are no security updates, people can not apply them. So what is > worse? If people stop applying updates, then it is at least their > decision. If there are no updates, people can only choose not to use Many people are going to just pull updates. They aren't going to make a decision on their own. Security updates aren't all created equal. While the case that was referenced in this was easily remotely exploitable, not all security issues expose a system to that level of risk. > The optimal case is to provide well tested security updates fast, but > this is not what Fedora achieves. In my example there is no indication > that the update was especially tested, because it did not get any karma. > And it was not provided fast. There is definitely a problem that needs fixing. But I don't think changing the goal to untested security updates provided quickly is the preferred solution. Perhaps we should have a way to draw attention to high priority updates. Generally we need more testers and need to make them more efficient. (Test plans for packages can make testing more efficient and accurate.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 12:41 AM, Richard W.M. Jones wrote: > On Fri, Nov 12, 2010 at 06:26:48PM +, "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. > > | * 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: > > - You can expand the root filesystem (eg. into spare space or > across block devices). > > - You can live pvmove filesystems from one device to another. > > 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? Something else to add to the list: Does not support discard (aka TRIM) when using SSDs which hurts performance and lifetime of said drives. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 09:57 AM, drago01 wrote: > Something else to add to the list: Does not support discard (aka TRIM) > when using SSDs which hurts performance and lifetime of said drives. I have a btrfs file system inside of a LVM inside of a software RAID0 array on two Intel SSDs mounted with "discard" enabled. Am I being lied to about discard being enabled? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 5:41 PM, Michael Cronenworth wrote: > On 11/14/2010 09:57 AM, drago01 wrote: >> Something else to add to the list: Does not support discard (aka TRIM) >> when using SSDs which hurts performance and lifetime of said drives. > > I have a btrfs file system inside of a LVM inside of a software RAID0 > array on two Intel SSDs mounted with "discard" enabled. Am I being lied > to about discard being enabled? Yes unless something changed recently the filesystem's discard command never reaches the drive. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 10:42 AM, drago01 wrote: > Yes unless something changed recently the filesystem's discard command > never reaches the drive. Looks like I'm reformatting and dumping the LVM. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, 2010-11-13 at 11:15 -0500, Genes MailLists wrote: > On 11/13/2010 10:45 AM, Owen Taylor wrote: > > On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote: > >> Kevin Fenzi writes: > >> > >>> * gnome3 / gnome-shell default > >> > > > Does anyone happen to know how to mimic the equivalent of panel > applets esp those which are not a part of fedora > > e.g. I use mathematica all the time and in gnome 2.x I put an icon on > the panel. > >The only way I could see so far from looking at the gnome-3 website > is to ALT-F2 to start an application - then right click to add the app > to 'favorites' ... Anything installing an application on the system (whether it's part of Fedora or not) really should be installing a desktop file. If there's no desktop file, there's no way for the user to launch the application. In GNOME 3, no desktop file also means that it won't behave properly as an application it won't get the right name and icon in the top panel, etc. Once there is a desktop file, then, yes you would add it to favorites. Favorite are very close in function to a launcher on the panel - you can get to them with a single mouse-click using the "hot corner" activation of the Activities Overview. (If Mathematica has a desktop file and it's just not being picked up by GNOME 3, then creating a symlink into ~/.local/share/applications will work.) Is there going to be a GUI to create a desktop file for a something that doesn't have a desktop file? (Something like the "Add custom launcher" dialog for gnome-panel currently.) It's not in our plans currently, and I'm not really sure where it would neatly fit into the user interface. One possibility is the one you mentioned - if someone starts an application that we don't recognize and tries to make it a favorite, we prompt them for the missing information and create a desktop file in ~/.local/share/applications. But really, it's something that ISVs have to get right and anything else is a workaround. - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Hi. On Sun, 14 Nov 2010 10:44:06 -0600, Michael Cronenworth wrote > Looks like I'm reformatting and dumping the LVM. Thanks. Discard aside, btrfs should include all (or most of) the features that LVM and raid0 were giving you, anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: build rpm packages such as Redhat/Fedora
On 11/13/2010 18:15, Christopher Stolzenberg wrote: > yum install mock > useradd mockbuild > usermod -G mock mockbuild Unless you want to ``su'' to a dedicated mockbuild account every time you want to build you should add your usual account to the mock group instead. > mock rebuild -r epel-6-x86_64 /home/mockbuild/kernel-2.6.32-71.7.1.el6.src.rpm Mock typically grabs packages from CentOS, so until CentOS 6 is out you're going to have to build using RHEL 6. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 12:15 PM, Owen Taylor wrote: > > Anything installing an application on the system (whether it's part of > Fedora or not) really should be installing a desktop file. If there's no > desktop file, there's no way for the user to launch the application. > > In GNOME 3, no desktop file also means that it won't behave properly as > an application it won't get the right name and icon in the top > panel, etc. > > Once there is a desktop file, then, yes you would add it to favorites. > Favorite are very close in function to a launcher on the panel - you can > get to them with a single mouse-click using the "hot corner" activation > of the Activities Overview. > > (If Mathematica has a desktop file and it's just not being picked up by > GNOME 3, then creating a symlink into ~/.local/share/applications will > work.) > > Is there going to be a GUI to create a desktop file for a something that > doesn't have a desktop file? (Something like the "Add custom launcher" > dialog for gnome-panel currently.) It's not in our plans currently, and > I'm not really sure where it would neatly fit into the user interface. > > One possibility is the one you mentioned - if someone starts an > application that we don't recognize and tries to make it a favorite, we > prompt them for the missing information and create a desktop file in > ~/.local/share/applications. But really, it's something that ISVs have > to get right and anything else is a workaround. > I have a lot of non-fedora applications I added via the 'custom launcher' tool - it would be really nice to be able to do this - whether its mathematica or sometimes its upstream versions of apps (I use test versions of thunderbird for example) as well as a bunch of other apps. Certainly be nice if gnome 3 made it as easy as it is in gnome 2 ... thanks for your thoughts. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans - BTRFS
> btfrs providing raid0 functionality. Does BTRFS have the equivalent of raid 5 ? gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: > Anyway, I think LVM is jolly useful: [stated advantages snipped] One design error is that you cannot "carve out" an ordinary partition from an LVM. Once a portion of the drive is LVM, then that portion of the drive is LVM forever until the LVM is completely gone. This makes LVM a bad neighbor in a consulting environment where flexibility is king: multiple systems per drive, and many of the systems do not understand LVM. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates to static library packages
On Sat, Nov 13, 2010 at 11:38:50PM +, Michel Alexandre Salim wrote: > I'd say do try a rebuild of affected packages yourself, and notify the > maintainers only in case there is a breakage and coordinate on what to do > (otherwise they'd get an unpleasant FTBFS report). > That was helpful, thank you :) -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote: > On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: > > > Anyway, I think LVM is jolly useful: > [stated advantages snipped] > > One design error is that you cannot "carve out" an ordinary partition > from an LVM. Once a portion of the drive is LVM, then that portion of > the drive is LVM forever until the LVM is completely gone. That's not true. You can shrink the PV with pvresize and then create any desired partitions in the resulting space. Or did you mean something different? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote: > On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote: > > On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: > > > > > Anyway, I think LVM is jolly useful: > > [stated advantages snipped] > > > > One design error is that you cannot "carve out" an ordinary partition > > from an LVM. Once a portion of the drive is LVM, then that portion of > > the drive is LVM forever until the LVM is completely gone. > > That's not true. You can shrink the PV with pvresize and then create > any desired partitions in the resulting space. Oops, that's not completely true: pvresize currently is not smart enough to move allocated data out of the area to be freed, according to its man page. But you have other options, e.g., you can attach another disk, create a PV on it, move the data there, rearrange the first disk as desired, and move the data back, all while the system is running. That's what's so fun about LVM. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Matt McCutchen wrote: > On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote: > Oops, that's not completely true: pvresize currently is not smart enough > to move allocated data out of the area to be freed, according to its man > page. But you have other options, e.g., you can attach another disk, > create a PV on it, move the data there, rearrange the first disk as > desired, and move the data back, all while the system is running. > That's what's so fun about LVM. Even if pvresize doesn't move allocated data, you can do that with pvmove, and you do not need to move everything out of the PV, just the part you are going to truncate (PEs can be specified). I don't remember if pvmove can use the same PV as src and dest; in that case you could avoid the need of an extra disk when your PV is just "fragmented". -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 05:44 PM, Michael Cronenworth wrote: > On 11/14/2010 10:42 AM, drago01 wrote: >> Yes unless something changed recently the filesystem's discard command >> never reaches the drive. > > Looks like I'm reformatting and dumping the LVM. Thanks. You should also file a bug against the tool that told you that discard support is available. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 11:07 AM, Matt McCutchen wrote: > On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote: >> On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: >> >>> Anyway, I think LVM is jolly useful: >> [stated advantages snipped] >> >> One design error is that you cannot "carve out" an ordinary partition >> from an LVM. Once a portion of the drive is LVM, then that portion of >> the drive is LVM forever until the LVM is completely gone. > > That's not true. You can shrink the PV with pvresize and then create > any desired partitions in the resulting space. Or did you mean > something different? When I created 14 partitions using a DOS partition label (3 primaries, plus extended containing 10 logical partitions) and gave 6 of the partitions to an LVM setup, then I could not remove one of the partitions from the clutches of the LVM, and use the removed partition for some other purpose (keeping the rest of the LVM going), unless I removed all the LVM from that drive. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans - BTRFS
On 11/14/2010 07:03 PM, Genes MailLists wrote: > > >> btfrs providing raid0 functionality. > > Does BTRFS have the equivalent of raid 5 ? Apparently that's being worked on: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Raid5.2F6 Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 14 Nov 2010 10:41:00 -0600, Michael Cronenworth wrote: > On 11/14/2010 09:57 AM, drago01 wrote: > I have a btrfs file system inside of a LVM inside of a software RAID0 > array on two Intel SSDs mounted with "discard" enabled. Am I being lied > to about discard being enabled? You probably want to use btrfs's own soft RAID rather than md-raid. Regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (LVM issues)
On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote: > When I created 14 partitions using a DOS partition label > (3 primaries, plus extended containing 10 logical partitions) > and gave 6 of the partitions to an LVM setup, > then I could not remove one of the partitions from the clutches > of the LVM, and use the removed partition for some other purpose > (keeping the rest of the LVM going), unless I removed all the LVM > from that drive. vgreduce + pvremove? Did something go wrong when you tried? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mysterious Heisenbug involving pdflatex on Koji's F-13 build servers
Rebuilding the same package without any change fixes the issue. Anyone has any idea what's going on here? Thanks, -- Michel -- Forwarded message -- From: Fedora Koji Build System Date: Sun, Nov 14, 2010 at 9:29 PM Subject: Package: pdfjam-2.07-1.fc13 Tag: dist-f13-updates-candidate Status: failed Built by: salimma To: voro...@fedoraproject.org, torwan...@fedoraproject.org, alaguna...@fedoraproject.org, ur...@fedoraproject.org, sali...@fedoraproject.org, jkeat...@fedoraproject.org Package: pdfjam-2.07-1.fc13 Tag: dist-f13-updates-candidate Status: failed Built by: salimma ID: 204909 Started: Sun, 14 Nov 2010 20:26:50 UTC Finished: Sun, 14 Nov 2010 20:29:40 UTC pdfjam-2.07-1.fc13 (204909) failed on x86-18.phx2.fedoraproject.org (noarch), x86-20.phx2.fedoraproject.org (noarch): BuildError: error building package (arch noarch), mock exited with status 1; see build.log for more information SRPMS: pdfjam-2.07-1.fc13.src.rpm Failed tasks: - Task 2600765 on x86-18.phx2.fedoraproject.org Task Type: buildArch (pdfjam-2.07-1.fc13.src.rpm, noarch) logs: http://koji.fedoraproject.org/koji/getfile?taskID=2600765&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2600765&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=2600765&name=state.log Task 2600759 on x86-20.phx2.fedoraproject.org Task Type: build (dist-f13-updates-candidate, /pdfjam:0f3817615bbfac99f04419cad4ef5c1a1920bb62) Closed tasks: - Task 2600760 on x86-03.phx2.fedoraproject.org Task Type: buildSRPMFromSCM (/pdfjam:0f3817615bbfac99f04419cad4ef5c1a1920bb62) logs: http://koji.fedoraproject.org/koji/getfile?taskID=2600760&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2600760&name=checkout.log http://koji.fedoraproject.org/koji/getfile?taskID=2600760&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=2600760&name=state.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2600759 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=204909 -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans - BTRFS
On Sun, 2010-11-14 at 13:03 -0500, Genes MailLists wrote: > > > btfrs providing raid0 functionality. > >Does BTRFS have the equivalent of raid 5 ? I implemented most of what's needed for RAID5 (and RAID6) a year or so ago. It's waiting on Chris to do the final bits in the upper layers which are required to ensure we only ever write a full stripe. That should allegedly be Real Soon Now. Although he's been saying that for quite a long time... :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Once upon a time, Roberto Ragusa said: > I don't remember if pvmove can use the same PV as src and dest; > in that case you could avoid the need of an extra disk > when your PV is just "fragmented". You can; you have to specify manually the source and destination PEs, and IIRC there's an extra option required to force it. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 10:38:37AM -0800, John Reiser wrote: > On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: > > > Anyway, I think LVM is jolly useful: > [stated advantages snipped] > > One design error is that you cannot "carve out" an ordinary partition > from an LVM. Once a portion of the drive is LVM, then that portion of > the drive is LVM forever until the LVM is completely gone. > This makes LVM a bad neighbor in a consulting environment where > flexibility is king: multiple systems per drive, and many of > the systems do not understand LVM. This is a problem of partitions themselves being very inflexible. Have said that I don't really understand why you'd ever want to do this. "In a consulting environment" you're much more likely to encounter some other mechanism for creating LUNs of the right size on demand, ie. SANs. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 01:07:28PM -0800, John Reiser wrote: > On 11/14/2010 11:07 AM, Matt McCutchen wrote: > > On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote: > >> On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: > >> > >>> Anyway, I think LVM is jolly useful: > >> [stated advantages snipped] > >> > >> One design error is that you cannot "carve out" an ordinary partition > >> from an LVM. Once a portion of the drive is LVM, then that portion of > >> the drive is LVM forever until the LVM is completely gone. > > > > That's not true. You can shrink the PV with pvresize and then create > > any desired partitions in the resulting space. Or did you mean > > something different? > > When I created 14 partitions using a DOS partition label > (3 primaries, plus extended containing 10 logical partitions) > and gave 6 of the partitions to an LVM setup, > then I could not remove one of the partitions from the clutches > of the LVM, and use the removed partition for some other purpose > (keeping the rest of the LVM going), unless I removed all the LVM > from that drive. Quite probably the PV contained some allocated PE. As another respondant said, you can [manually, it is a little cumbersome with the current tools] pvmove PEs around. In any case I have no idea why you'd be using 14 partitions with MBR. Really you should use GPT which resolves at least that shortcoming of MBR. MBR logical partitions are vulnerable to an error in a single sector completely wiping out the chain of logical partitions. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (LVM issues)
On 11/14/2010 01:13 PM, Matt McCutchen wrote: > On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote: >> When I created 14 partitions using a DOS partition label >> (3 primaries, plus extended containing 10 logical partitions) >> and gave 6 of the partitions to an LVM setup, >> then I could not remove one of the partitions from the clutches >> of the LVM, and use the removed partition for some other purpose >> (keeping the rest of the LVM going), unless I removed all the LVM >> from that drive. > > vgreduce + pvremove? Did something go wrong when you tried? vgreduce would not let go of the partition that I wanted to take back, claiming that the partition was still in use. - DESCRIPTION vgreduce allows you to remove one or more *unused* physical volumes from a volume group. [emphasis added] - I could not find a way to evict any usage of that partition (transparently move the information somewhere else in the same LVM) as a prelude to applying vgreduce. In theory I could have moved all of the LVM onto another drive, but I wanted to keep the LVM going on that drive, with the same user-visible information content [there was enough free space], but without using one particular partition that I had given [loaned] to LVM some time before. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans - BTRFS
On 11/14/2010 04:26 PM, David Woodhouse wrote: >> >>Does BTRFS have the equivalent of raid 5 ? > > I implemented most of what's needed for RAID5 (and RAID6) a year or so > ago. > > It's waiting on Chris to do the final bits in the upper layers which are > required to ensure we only ever write a full stripe. > > That should allegedly be Real Soon Now. Although he's been saying that > for quite a long time... :) > Thats really really good news ... :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote: > We definitely should stop setting up LVM by default on Fedora, because > it allows us to disable these unnecessary enumeration delays that are > broken by design anyway. > > If we don't have LVM on default installs, we also don't need > scsi_wait_scan anymore, and that would be great. Wow. LVM is important and useful for managing storage. If, in the future, we have ZFS-like features in btrfs or whatever, okay, we can talk about getting rid of it. But a few-second gain in boot time is really, really, really not worth it. And yeah, I mean the desktop/laptop case, not just servers. (In fact, with suspend/hibernate working so well these days, I think I reboot my servers more often than my laptop.) -- Matthew Miller Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mysterious Heisenbug involving pdflatex on Koji's F-13 build servers
On Sun, Nov 14, 2010 at 21:23, Michel Alexandre Salim wrote: > Rebuilding the same package without any change fixes the issue. Anyone > has any idea what's going on here? No idea, but you might be on the way to an hexadecimal dollar! Regards, -- Pierre Carrier -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (LVM issues)
On 11/15/2010 12:00 AM, John Reiser wrote: > On 11/14/2010 01:13 PM, Matt McCutchen wrote: >> On Sun, 2010-11-14 at 13:07 -0800, John Reiser wrote: >>> When I created 14 partitions using a DOS partition label >>> (3 primaries, plus extended containing 10 logical partitions) >>> and gave 6 of the partitions to an LVM setup, >>> then I could not remove one of the partitions from the clutches >>> of the LVM, and use the removed partition for some other purpose >>> (keeping the rest of the LVM going), unless I removed all the LVM >>> from that drive. >> >> vgreduce + pvremove? Did something go wrong when you tried? > > vgreduce would not let go of the partition that I wanted to take back, > claiming that the partition was still in use. > - > DESCRIPTION > vgreduce allows you to remove one or more *unused* physical volumes > from a volume group. [emphasis added] > - > I could not find a way to evict any usage of that partition (transparently > move the information somewhere else in the same LVM) as a prelude to applying > vgreduce. In theory I could have moved all of the LVM onto another drive, > but I wanted to keep the LVM going on that drive, with the same user-visible > information content [there was enough free space], but without using one > particular partition that I had given [loaned] to LVM some time before. > pvmove is the command you need to use before doing a vgreduce. That's basically what I did with the 30TB system that I mentioned elsewhere in this thread. This system was partitioned into 10 raid-5 volumes and one of those acted up when we put the system into production (it was already pre-filled with data). So what I did was a pvmove to clear out the physical volume which took a few hours and then I removed the physical volume from the volume group. The fact that I could do all of this while the system stayed online and was being used was a real life saver. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 07:48:36PM -0500, Matthew Miller wrote: > LVM is important and useful for managing storage. If, in the future, we have > ZFS-like features in btrfs or whatever, okay, we can talk about getting rid > of it. But a few-second gain in boot time is really, really, really not > worth it. And yeah, I mean the desktop/laptop case, not just servers. (In > fact, with suspend/hibernate working so well these days, I think I reboot my > servers more often than my laptop.) LVM's a fantasically useful tool in a wide range of cases, but I don't think that in the *typical* laptop/desktop install any of that functionality ever gets used. The question is really whether there's enough people that know nothing about LVM at install time but will make use of it later that doing it by default is beneficial - if not, there's a reasonable argument for it being a well-tested optional feature at least, although it would obviously be preferable to address its shortcomings to the point where there's no desire to do so. But that would involve someone who understands the issues sufficiently to be doing the work. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 10:42:05PM +, Richard W.M. Jones wrote: > This is a problem of partitions themselves being very inflexible. > Have said that I don't really understand why you'd ever want to do > this. "In a consulting environment" you're much more likely to > encounter some other mechanism for creating LUNs of the right size on > demand, ie. SANs. It's also a problem of our user-friendly tools being woefully poor at dealing with LVM. I can resize a filesystem-containing partition far more straightforwardly than I can an LVM-containing one. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
