Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Merging code in-flight, just because I can. What timezone should I
use?
-- Linus
Torvalds (thanks to Cesar Eduardo Barros)
Fedora is now getting so weird and dependant on magic initrds it's
become pretty unusable for kernel development work nowdays IMHO
because it's undebuggable.
-- Alan Cox
...our goal remains to provide a desktop which by default works for
the 99%, but that we also think that those we do like to tweak
their desktops should have an easy method to do so.
-- Olav Vitters; prepare for "Occupy LKML"
in the near futureNote my wording: 99% excludes kernel hackers. Not sure if we should say something about that explicitly or not. (Log in to post comments)
Quotes of the week Posted Nov 24, 2011 10:29 UTC (Thu) by dgm (subscriber, #49227) [Link]
> Merging code in-flight, just because I can. What timezone should I use?
UTC, of course. What else could make any sense at all?
Quotes of the week Posted Nov 24, 2011 11:40 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> UTC, of course. What else could make any sense at all?
* The timezone of the departure airport.
time zone for merging code on the plane Posted Nov 24, 2011 19:33 UTC (Thu) by giraffedata (subscriber, #1954) [Link] I'm sure "what else could make any sense at all" is hyperbole, as all of your suggestions make a little sense. But none of them should be given more than a moment's consideration. In fact, in the Internet age, everyone should use UTC for everything. I am dismayed to find out time zones are involved in merging Linux kernel code. Incidentally, the timezone of the departure airport has tradition behind it. Local time first began to be a PITA with the advent of trains, which traveled at a steady enough speed that it made sense to compare time of day between two points in space. The convention, in the US, at least, was that the time of day on the train was the TOD at the beginning of the line. Later, time zones were invented. "The timezone of air traffic control for the area you are in"? My understanding is that air traffic control uses UTC. They're no dummies.
Quotes of the week Posted Nov 25, 2011 0:30 UTC (Fri) by dgm (subscriber, #49227) [Link]
> * The timezone of the departure airport.
... you're no longer at. > * The timezone of the arrival airport. ... you're not still at. > * The timezone you are flying over at the moment (if over land). ... that you ignore because you don't have a GPS handy. > * The timezone of air traffic control for the area you are in. ...that you also ignore because, you know, that's a pilot's thing. > * A timezone calculated based on your current longitude. We don't have a GPS, remember? >* The timezone at your home city. ... no comment
Quotes of the week Posted Nov 25, 2011 3:40 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]
Well, depending on how far and what direction you're flying, all of these may be the same timezone, or fall into a pair of timezones, so in the end, does it really matter?
Quotes of the week Posted Nov 25, 2011 11:30 UTC (Fri) by dgm (subscriber, #49227) [Link]
> Well, depending on how far and what direction you're flying [...]
Don't look at my finger, I'm trying to show you the Moon.
The problem is localtime, and specifically storing it, because it's, well, local. Your possition is not static, you're not a tree or a rock, neither is your laptop or your phone. Servers are static, but can be shared by users is many timezones, so it really doesn't make sense either. What's left? Only desktop machines. Does it make sense to work in localtime with those? Not really. Why make an exception for desktop machines when the rest of the World does things right? Just because you can? Not the brightest idea, don't you agree?
Quotes of the week Posted Nov 25, 2011 17:42 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] If you look at the commit, it has the commit time in UTC, as well as a rendering in "localtime." The commit timezone really is there to capture some amount of "useful to the human" context, and so it really is arbitrary. The code underneath still keeps track of the UTC:
committer Linus Torvalds <torvalds@linux-foundation.org>
Sat, 19 Nov 2011 18:56:01 +0000 (10:56 -0800)
I fully agree that tracking the official time in localtime only is bad, bad idea. I even set my computer's CMOS clock to UTC when possible. But rendering the time in localtime is very human friendly. I prefer my software to show me localtime even if it's tracking UTC under the hood. Linus' comment really has to do with what timezone to choose for displaying the commit time, I'm sure. "It's 11AM where I'm at now when I commit this." The "where I'm at now" part will surely change in the future, but it's perfectly serviceable metadata to store with the commit.
Quotes of the week Posted Nov 25, 2011 18:40 UTC (Fri) by nix (subscriber, #2304) [Link] The commit timezone really is there to capture some amount of "useful to the human" context, and so it really is arbitrary.Well, yes, except that the code relies on it ('git name-rev', 'git describe --contains', etc use it).
Quotes of the week Posted Nov 25, 2011 22:34 UTC (Fri) by jrn (subscriber, #64214) [Link]
No, rev-list makes use of the commit time in UTC, but the timezone really is for display only.
Quotes of the week Posted Nov 25, 2011 9:31 UTC (Fri) by cesarb (subscriber, #6266) [Link]
> don't have a GPS
What if it is one of those planes which shows the plane's own GPS information on a screen?
> you know, that's a pilot's thing
What if it is one of those planes where you can listen to the air-to-ground communications in one of the audio channels?
> * The timezone at your home city.
This might sound like a joke, but IIRC it has been used by astronauts (the timezone they used was the one at mission control). Of all my joke suggestions, this is perhaps the one which makes the most sense.
Quotes of the week Posted Nov 25, 2011 9:34 UTC (Fri) by neiljerram (subscriber, #12005) [Link]
s/still/yet/
s/ignore/don't know/
(These are common "false friends" when translating from French to English.)
Quotes of the week Posted Nov 25, 2011 11:34 UTC (Fri) by dgm (subscriber, #49227) [Link]
And apparently when translating from other latin languages too... My native language is Catalan. Thanks for the lesson, btw. ;-)
Quotes of the week Posted Nov 25, 2011 22:47 UTC (Fri) by Per_Bothner (subscriber, #7375) [Link] ... that you ignore because you don't have a GPS handy.GPS can work tolerably well on a plane, especially if near a window. The FTA doesn't have a policy prohibiting use of a GPS; generally it's up to the pilot whether they're allowed. (At least in our experience.) If the plane has and allows WiFi there seems to be no reason not to.
Quotes of the week Posted Nov 26, 2011 19:36 UTC (Sat) by dmk (subscriber, #50141) [Link]
Consumer GPS devices are passive sensors. I don't think they could sensibly be forbidden on an airplane?
Quotes of the week Posted Nov 26, 2011 20:08 UTC (Sat) by Per_Bothner (subscriber, #7375) [Link] Consumer GPS devices are passive sensors. I don't think they could sensibly be forbidden on an airplane?
If you've flown in the last 10 years, you should know that
But note that even a [*] In the UK they used to have detector vans that could detect television sets, used to catch people who hadn't paid the mandatory license fee - though my impression it worked better as a deterrent than anything else.
Quotes of the week Posted Nov 26, 2011 21:44 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
if airplanes were even 1% as sensitive to electronics as they are made out to be, all that the terrorists would have to do to take down airplanes is to ship a crate of electronics set to wake up shortly before landing and they could take down hundreds of planes
Quotes of the week Posted Nov 26, 2011 23:17 UTC (Sat) by nix (subscriber, #2304) [Link]
Quite. TV license detector vans were plausible (and worked), though they couldn't detect every case where someone should pay the license fee (e.g. they didn't work if the TV was off).
For an example of something similar that simply fails to work, I submit the "pirate software detector vans" that FAST drove around for a while to intimidate total idiots.
The infamous TV detector van Posted Nov 27, 2011 21:35 UTC (Sun) by man_ls (subscriber, #15091) [Link] Apparently the technical details are not public. I assume they detected the 15.625 kHz noise emitted by the line frequency of old cathodic ray tubes? (625 lines x 25 images per second = 15625.) It was a distinct pitch easily detectable if you had good ears (and I did back then).Nowadays with LCD TVs they are not only identical to computer monitors, but there should be no emitted sounds at all. The BBC might be using signal strength attenuation, which I have seen suggested as a method for detecting TV antennas in operation; but my guess is that they just bluff it. Still, has any method ever worked in practice?
The infamous TV detector van Posted Nov 28, 2011 2:11 UTC (Mon) by nix (subscriber, #2304) [Link]
Oh, that BoingBoing article has some hilarious comments, like the cable TV guy who posted a lengthy and interesting comment on signal leakage detection from cables on the assumption that the BBC is a cable-TV outfit. Uh, no, it started in 1927. Not much cable about back then...
But, no, it wasn't anything to do with CRT tubes they picked up: it was the local oscillator radiation from the superhet receivers in the TV, which has the advantage of being unavoidable no matter what display technology is in use. There were few enough channels that they could easily tell if you were watching TV (and what channel) or listening to the radio, and even tease apart mixes from nearby antennae to tell if you were listening to radio and watching TV in different rooms. It was short-range enough that they could limit it to a few houses (flats were a bit of a bugger though). Even now, with digital TV, they should be able to tell that you're watching something, though they probably can't tell which channel you're watching or distinguish it from digital radio (but who listens to that?). However, it may be true that the radiation is so weak now, and the spectrum so noisy, that they'd need to be only metres or centimetres away, in which case the vans have in effect become useless. I don't know: it's been many years since I had any contact with TV licensing, thank goodness.
But I'm amazed that this is even in contention. I thought this was something everyone knew who'd paid attention to TV detector vans at all. They're not magic.
The infamous TV detector van Posted Dec 2, 2011 2:06 UTC (Fri) by Wol (guest, #4433) [Link]
I doubt it. They could detect what frequency your receiver was tuned to, and hence what channel you were watching.
What they couldn't do was detect whether you needed a licence - and no you do NOT always need a licence. I got a formal apology from the detector people because they wrongly accused my daughter of watching an unlicenced TV.
(For furriners, the licence is for an address, but you don't need to be at the address on the licence to be covered by it. My daughter was at Uni, which was EXplicitly permitted.)
Cheers,
The infamous TV detector van Posted Dec 2, 2011 18:53 UTC (Fri) by nix (subscriber, #2304) [Link] What they couldn't do was detect whether you needed a licenceIndeed. The automated mobile legal analysis system has yet to be invented (the closest we have are things called 'policemen' and are a) not always right and b) have better things to do than chase up people without TV licenses). So we rely on Crapita instead.
The infamous TV detector van Posted Dec 5, 2011 15:39 UTC (Mon) by nye (guest, #51576) [Link]
>For furriners, the licence is for an address, but you don't need to be at the address on the licence to be covered by it. My daughter was at Uni, which was EXplicitly permitted
So she was only using an entirely self-contained device powered solely by an internal battery and using its own built-in aerial? I guess a laptop using WiFi would qualify as long as you don't plug it in while watching iPlayer.
(Those are the only circumstances in which a licence for one address covers another address. In fact when I read the small print a few years ago it was stricter than that: the device needed to be *incapable* of being externally powered. The TV licensing website doesn't say that though so I guess that loophole has been opened.)
Quotes of the week Posted Nov 26, 2011 16:25 UTC (Sat) by SEJeff (subscriber, #51588) [Link]
Air traffic control and all pilots (in the military at least) use Zulu time which is UTC. I was a Shadow 200 TUAV pilot in the US Army 6 years ago.
Quotes of the week Posted Dec 1, 2011 4:34 UTC (Thu) by kevinm (guest, #69913) [Link]
> * The timezone you are flying over at the moment (if over land).
> * The timezone of air traffic control for the area you are in. > * A timezone calculated based on your current longitude.
These options are subject to obvious race conditions, and thus would be avoided by sensible kernel hackers.
Fedora Posted Nov 24, 2011 10:41 UTC (Thu) by epa (subscriber, #39769) [Link]
I'm glad I'm not the only one who finds Fedora's boot sequence hard to diagnose when it goes wrong. (For example with Slackware it was a simple operation to add a second hard disk to your computer, transfer stuff across, then remove the old disk.) If even Alan Cox has difficulty what hope is there for the rest of us?
Hopefully the removal of LVM by default will simplify matters a bit, but I would still prefer to do without an initrd altogether if possible. (The original rationale of saving memory by loading drivers as kernel modules no longer applies - I'd rather lose a megabyte or two of RAM in exchange for the greater simplicity. And those with memory-constrained systems will be running a custom kernel anyway.)
Fedora Posted Nov 24, 2011 20:05 UTC (Thu) by jcm (subscriber, #18262) [Link]
Removal of LVM by default must be countered as strongly as possible. LVM is a critical technology for anyone who uses Linux seriously to manage their block devices adequately.
Fedora Posted Nov 24, 2011 20:43 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
I'm pretty convinced that I use Linux seriously, and I haven't had any situations where LVM would have made my life significantly easier for a very long time - on the contrary, it's been an irritant in the installs where I've ended up with it. It's a functional technology for some specific use-cases, and most Linux users will never go near them. Thankfully, btrfs will give us almost all of the benefits with approximately none of the drawbacks. Everyone wins.
Fedora Posted Nov 26, 2011 11:54 UTC (Sat) by jcm (subscriber, #18262) [Link]
I can't speak for you Matthew but in my experience, LVM and volume management is an essential component of a modern Unix workstation and Enterprise Linux Server (as opposed to a consumer Linux laptop). Since I am most interested in Linux use in the enterprise and model my own use on that, I find that I rely extensively on volume management features always layered on RAID. Just this week I had cause to use both LVM and RAID features directly as I migrated volumes onto new disks, then had a disk in a RAID set fail and need replacing (all without any data loss or resort to backup).
Jon (who runs LVM on everything, laptops and netbooks included).
Fedora Posted Nov 26, 2011 15:22 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
RAID is a great idea that's as relevant in the home as it is in the enterprise. LVM is only really useful if you have multiple drives[1] or have set up multiple partitions, both of which are uncommon. It's not a critical technology for me. My block devices are managed entirely adequately. So, for your original statement to be true, you feel that I don't use Linux seriously?
[1] Outside of RAID, obviously
Fedora Posted Nov 27, 2011 14:42 UTC (Sun) by fuhchee (subscriber, #40059) [Link]
"LVM is only really useful if [...] or have set up multiple partitions, both of which are uncommon."
Are they? What mainstream distro doesn't use multiple partitions by default?
Fedora Posted Nov 27, 2011 14:47 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Beyond /boot, which you basically never need to resize?
Fedora Posted Nov 27, 2011 20:56 UTC (Sun) by drago01 (subscriber, #50715) [Link]
Without fancy stuff like LVM there is no reason for a separate /boot to begin with.
Fedora Posted Nov 27, 2011 21:38 UTC (Sun) by raven667 (subscriber, #5198) [Link]
/boot is still used because the boot loader can't boot off every filesystem or read every block on disk
What I'd be interested in is a pure EFI system that doesnt have a separate boot loader at all and only uses the boot partitions of the firmware
Fedora Posted Nov 27, 2011 22:42 UTC (Sun) by jcm (subscriber, #18262) [Link]
Once everyone is using btrfs, I suspect there will be an attempt to kill off /boot. At the same time, you will tear my real ENTERPRISE volume management from my cold dead hands.
Fedora Posted Nov 28, 2011 8:46 UTC (Mon) by drago01 (subscriber, #50715) [Link]
> At the same time, you will tear my real ENTERPRISE volume management from my cold dead hands.
No one suggested that. The talk was about *defaults*.
Fedora Posted Nov 28, 2011 11:54 UTC (Mon) by jcm (subscriber, #18262) [Link]
We all know what happens when you turn off a default. Clicking or unclicking a box is effort, as is writing a kickstart file, etc. Then before you know it, oops, something doesn't work when you use LVM (or next I'm sure it'll be RAID, because it's not very laptop-y) because it's not being used. It is *important* that features like LVM receive as widespread use and testing as possible, and they do not harm the average consumer (if you really want to target them). Instead, I suggest flipping this around: *you* should turn off LVM if you don't want it :)
Why should it be MY problem? Posted Nov 28, 2011 13:16 UTC (Mon) by khim (subscriber, #9252) [Link] It is *important* that features like LVM receive as widespread use and testing as possible, and they do not harm the average consumer (if you really want to target them). This one single sentence is internally inconsistent. Either they do not harm the average consumer (because everything is just works and never breaks) or it is *important* that features like LVM receive as widespread use and testing as possible (because it breaks and you need to keep in unbroken state). You can't have your cake and eat it too. Instead, I suggest flipping this around: *you* should turn off LVM if you don't want it :) Why should I suffer for your sake? If it's problematic to keep LVM working then it's time to drop it and make life for Joe Average easier. If it's not then it's safe to drop it anyway - it'll keep working regardless. When I start hearing phrase "you'll only take <something> from my cold dead hands" I undersatd that time of <something> is near. Time is merciless like that: it's answer to declarations like that is almost always "hmm... cold dead hands... that I can do". People can decide to rally together and protect <something> for some time, but it's rarely worth it: I understand that focus-follow-mouse is superior model in theory, but on practice it's just not worth fighting for. If <something> is really important for a lot of people then question rarely reaches this stage.
Why should it be MY problem? Posted Nov 28, 2011 20:37 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I'm not sure that your complaint really shows an inconsistency, I think it is a false analysis. Saying either "it's perfect and doesn't require testing so should be disabled" or "it's crap because it needs testing so it should be disabled" seems to be arguing backwards from the conclusion you desire "it should be disabled". A feature which is in widespread use because it is the default, should it get broken by a proposed change, will be fixed quickly, probably before ever shipping code to customers whereas a feature which is only used by a small minority may have to wait a long time.
It seems a reasonable to fear that a feature which goes from majority to minority use will necessarily have more accidental breakage and won't be a priority to support potentially inconveniencing existing users.
Why should it be MY problem? Posted Nov 28, 2011 21:05 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Addendum: The question of whether this feature should be used by default or if other advances have made it obsolete or if the common use case doesn't warrant it are other questions that can be subject to an honest debate.
Fedora Posted Nov 28, 2011 9:19 UTC (Mon) by anselm (subscriber, #2796) [Link] There's nothing wrong with /boot, the directory. If anything it keeps clutter out of /. As far as /boot, the separate file system is concerned, it's great to be able to do it but you don't need to do it if you don't have to. Today's distributions don't tend to put /boot on a separate file system unless you explicitly tell them to. If Linux can be booted off Btrfs, then there's no need to make a separate partition for /boot either, and that will be it even though the directory is likely to stick around.
Fedora Posted Nov 28, 2011 15:54 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Why would you want an extra layer of indirection between your filesystem and your block device when you only have a single partition on a single disk? Not that the number of partitions has a lot to do with it - in the single drive case LVM is irrelevant when determining the ease of filesystem resizing.
Fedora Posted Nov 28, 2011 19:14 UTC (Mon) by jcm (subscriber, #18262) [Link]
I would want this for at least the following reasons:
*). An ability to easily add additional disks to my system and treat them as a logical unit. An ability to also remove disks in the inverse way.
*). An ability to conveniently manage backups, migration of data, and provisioning of new storage as necessary (I do not provision all storage during installation, since it is convenient to assign some as needed).
*). An ability to wholesale encrypt every filesystem and swap as a unit.
*). etc. And the ability to choose to do any of these things later. On other Operating Systems, this stuff is available out of the box.
I don't care that you phrased this in terms of single disk laptops :) They are already more than covered by enthusiastic parties within Fedora and it is necessary to remember that there are still servers and real computers in this world with many disks that people will want to use. And yes, the downstream users of Fedora will be very unhappy if LVM goes away.
Jon.
Fedora Posted Nov 28, 2011 19:24 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Nobody's argued for the removal of LVM support, just for it to only be used when it makes sense for it to be used. The most common Fedora configurations gain no benefit from it.
Fedora Posted Nov 28, 2011 19:47 UTC (Mon) by jcm (subscriber, #18262) [Link]
Yea, and respectfully, I've stated my opinion that dropping its use by default will see it having much less testing and coverage. I think this is a net loss for Fedora and a terrible result, but another action that will likely happen anyway :) Eventually, we will have to revive that Server SIG and produce something viable from it for those of us motivated by the Enterprise use cases to have these things in a default installation.
Fedora Posted Nov 28, 2011 19:52 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
you don't want to have desktop specific things on your servers by default, why should deskop users have to have server specific things by default?
As for testing and coverage, I don't believe that having millions of desktop users have LVM running, but doing nothing other than providing the entire disk to the OS gains you any significant testing. All the 'interesting' parts of LVM will be completely untested by such people.
Fedora Posted Nov 28, 2011 20:14 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Respectfully, I'd find your arguments about your understanding of enterprise use cases much more compelling if you hadn't broken a traditional Unix use case in a module-init-tools update during a stable release and then ignored the bug for a month and a half until someone else finally uploaded the fix.
Simply asserting that everyone involved in the Fedora decision making process is incompetent to understand or satisfy user requests doesn't actually make it so, and if you think we're doing it wrong then you're more than welcome to get involved and help lead by example. It's just that up until now you (and anyone with similar opinions) have been notably absent from any of the bodies that help shape and direct the future of Fedora. A community-led project is inherently going to be influenced by the people who step up to do the work in it. You haven't been doing that, and so your opinions end up with significantly less weight.
Fedora Posted Nov 28, 2011 21:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>An ability to easily add additional disks to my system and treat them as a logical unit. An ability to also remove disks in the inverse way.
BRTFS does this.
>An ability to conveniently manage backups, migration of data, and provisioning of new storage as necessary (I do not provision all storage during installation, since it is convenient to assign some as needed).
BTRFS does this nicely using snapshots.
>An ability to wholesale encrypt every filesystem and swap as a unit.
That one is missing, however ecryptfs works fine for home directories.
So modern filesystems provide most if not all functionality of LVM, and with much better interface.
Fedora Posted Nov 28, 2011 22:09 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
only if you define btrfs as the only 'modern filesystem' (ok, if you want to include non-linux filesystems there is zfs as well)
LVM has it's place, but I don't see it on a system with only a single disk, and I don't think it's uses are common enough to be worth the complexity of having it used by default.
on the other hand, Fedora is for people willing to be guinea pigs, so it may make sense as part of it's 'bleeding edge' work to make all users test LVM
this is part of the reason I don't use Fedora :-)
Fedora Posted Nov 29, 2011 2:54 UTC (Tue) by raven667 (subscriber, #5198) [Link]
LVM is hardly bleeding edge, the Linux implementation is nearly a decade old and the concepts have been implemented elsewhere a decade or more before that. While filesystem design has taken a turn and started integrating LVM features directly into the filesystem itself, these are only relevant for btrfs, which is only now nearing production readiness, and zfs, which doesn't have a Linux implementation outside of FUSE.
In the future maybe only btrfs will matter and LVM will be redundant but that certainly isn't the past already.
Fedora Posted Nov 29, 2011 3:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
So, why would I need to install LVM on my notebook or even on a server with just two drives in RAID-1 mirror?
LVM complicates everything without additional benefits for 99.9% of cases. Especially on a desktop OS.
Fedora Posted Nov 29, 2011 6:19 UTC (Tue) by jcm (subscriber, #18262) [Link]
Everyone has different notions of "complicated". For example (silly example, not meant to offend anyone in particular!), I find installation of things like bash-completion by default "complicates" my use of a Linux machine by doing things I didn't ask it to do :) But apparently this is what people want out-of-the-box, and I can live with removing it from my machines.
The real issue, in my opinion, is how noticeable a technology is to you. I would argue that for the average out-of-the-box user LVM does not "complicate" their experience because they never even need know that it is there. The consumer of which we apparently seek knows not the difference between a block device or a device mapper device, or a flying duck device (although the last option sounds pretty awesome to me). As far as the average user is concerned, they install their system, and it works. And if LVM goes away it will probably still "work", for their use case.
Now, let's turn that around. If LVM goes away, valid use cases that I and others have will become more difficult, will receive less testing, and will run the risk of suffering from bitrot (in spite of I'm sure valiant efforts by all of those concerned). This means that a technology that the vast majority of users can ignore (and do today) because it "just works" is removed in the interest of avoiding "complication" and we go backwards. Then we end up in a situation where my Linux workstation is less useful to me than it was a decade or whatever ago, when I remember first struggling to figure out volume management on Linux. Fortunately, volume management changes fairly infrequently, so those who care about interacting with it directly have already learned and the documentation has been written.
If the real problem is the overhead of LVM then that should be the issue that is addressed, not ripping the whole thing out.
Jon.
Fedora Posted Nov 29, 2011 7:04 UTC (Tue) by adamg (subscriber, #42260) [Link]
Sometimes it makes sense to use LVM even on a single disk, it just depends on your needs. And it really doesn't complicate things that much - initrd generation is handled by system tools and all you need is to set proper fstab entries - if not done by installer.
I don't agree LVM doesn't provide any benefits. For example, I use vserver as a virtualization solution and each guest is sitting on a separate logical volume. I use lvcreate if I need to create a volume for new vserver and lvremove when it is no longer needed. And there is also DRBD on top of some of the logical volumes I use. It would be hard to get this without LVM.
BTRFS will replace LVM one day, but it is just not mature enough yet.
Fedora Posted Nov 29, 2011 7:26 UTC (Tue) by jcm (subscriber, #18262) [Link]
For my use case, btrfs is unlikely to ever completely replace LVM, but I can accept that there may come a time when:
0). The only filesystem anyone wants to use is btrfs, and it has been the default for a few releases to the point there's just no reason not to use it.
Having been burned by filesystems in the past (I've lost an array of data to reiserfs back in the day) I am very cautious about trusting something new when what I have already (ext3/4) gives me what I need today, but I can move with the times and will experiment with btrfs some more on a throwaway system or two. But change for the sake of change is a poor argument for throwing away LVM before it has been completely replaced in functionality.
Lastly, there are some great folks working on LVM, some of whom I have known for almost decades at this point, and I'm confident that they would want to improve aspects of LVM that don't seem satisfactory. The realities of life perhaps may get in the way, but don't count LVM out.
Jon.
Fedora Posted Nov 29, 2011 9:21 UTC (Tue) by adamg (subscriber, #42260) [Link] On the second thought, I see there is still place for lvm. Btrfs does not expose block devices, so it is not possible to combine drbd with btrfs.
Fedora Posted Nov 29, 2011 9:31 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
there are very few people who are advocating removing LVM, and you can ignore those people because they would equally advocate removing every other filesystem and raid implementation because they think that btrfs (or zfs) solve all problems.
there is a much larger group of people who dislike distros always using LVM, not on the basis that it makes life harder for the beginner, but that it makes life harder for those who have more knowledge and are able to go in under the covers more. At that point (especially when things have gone wrong), LVM adds significantly to the problems of recovering in many cases, and it's that much more that someone must learn to be able to deal with issues.
Fedora Posted Nov 29, 2011 10:17 UTC (Tue) by jcm (subscriber, #18262) [Link]
Once again, I would advocate for simply turning it off if you don't want it. It's pretty easy to go into manual partitioning in Fedora and turn off LVM. The problem comes if it is off by default we lose the benefit of having many oblivious users happily using something that is well supported and has great test coverage as a result.
Fedora Posted Nov 29, 2011 10:35 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
and this (bleeding edge testing on end users by default) is why I don't recommend Fedora to anyone, and don't support family on that distro.
I started with SLS, then Slackware, Then RedHat (before RHEL), dabbled with Gentoo and am now primarily using Debian and Ubuntu. I usually compile kernels myself from kernel.org, and have been making my living from supporting linux machines for the last 15 years, so I'm not exactly a newbe at this.
Since I don't use Fedora, I have no say over what the distro does, but I can say that this sort of thing is why I recommend against Fedora when asked.
Fedora Posted Nov 29, 2011 11:38 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
I don't see the value of LVM by default and it is likely to go away sometime after Btrfs become default but calling LVM bleeding edge testing is ridiculous beyond belief.
Fedora Posted Dec 1, 2011 20:14 UTC (Thu) by nix (subscriber, #2304) [Link]
I hope LVM doesn't go away, simply because partition tables can't be reread until all partitions on that block device have been closed. That makes simple use cases like 'I need more swap: shrink my one great big fs partition and its contained fs, add a new swap partition, mkswap and swapon it' impossible.
Fedora Posted Dec 2, 2011 1:56 UTC (Fri) by viro (subscriber, #7872) [Link]
For your case partx(8) will probably suffice; if not, see addpart(8) and
delpart(8).
It's _very_ easy to self-LART with the last two, though. Basically, you can set/remove partitions at will and it will only check that
Other partitions being busy are not a problem. You *can* shrink your partition, along with fs, add swap partition, write that to disk, then remove fs partition from kernel knowledge and set to new size, then set swap partition to match the on-disk table and you are done.
Cthulhu help you if you tell the kernel that new size is lower than what it really is and set swap partition not where partition table says it is, but in the area overlapping the actual fs. This is decidedly not for faint-hearted. *Always* check with something like fdisk -lus where they really are; you might want to have different partition numbers[*], but you really want to have _boundaries_ matching reality.
Again, if you really don't need to renumber anything mounted, partx(8) would be a safer and easier alternative.
[*] think of the case where sda5 is shrunk and carved up while root on sda6 is mounted. You can't change st_dev of mounted fs, or userland code will be Very Unhappy(tm). What you can do is setting sda15 to what will become sda6 after reboot, doing mkswap/swapon on it, remembering to have it mentioned in fstab, etc. as sda6. With boot loader told to use sda7 as root (known as sda6 until that reboot). Just make sure that you've documented what you've done (and that any cow-orker likely to be confused several months later by changes upon reboot and fsck the things up can be usefully sacrificed afterwards).
Fedora Posted Dec 2, 2011 18:51 UTC (Fri) by nix (subscriber, #2304) [Link]
Eeeew.
OK, so it *is* possible to tell the kernel that the partition table has changed -- but you have to do that separately from fdisk, and you get massive disk corruption if you get it wrong. How can anyone imagine that this is preferable to the corresponding LVM commands, which have near-zero probability of futzing the system if you typo?
(That fdisk does not do this already is a strong indication that this part of the system is barely maintained.)
Fedora Posted Dec 2, 2011 20:31 UTC (Fri) by viro (subscriber, #7872) [Link]
_Which_ fdisk? There are quite a few of those beasts floating around... I can think of at least 3, not counting e.g. parted (which happens to use those instead of BLKRRPART, BTW, so it will DTRT; so will gnu-fdisk, for that matter, since it uses libparted).
The real PITA starts when busy partitions would change numbers. Then you are seriously stuck, no matter what. Simply because you are doomed to have device => partition associations changed at some point between umount and next boot. And that's where "document everything and prepare obsidian knives" comes from, of course... You _can_ tell the kernel to play musical chairs with partition numbers; it will even work, but as always, delayed setup changes are forgotten setup changes.
Not that LVM didn't have its own ways to suck - it's software too and miracles do not exist...
Fedora Posted Dec 2, 2011 21:46 UTC (Fri) by nix (subscriber, #2304) [Link]
I was thinking of the util-linux fdisk (though, of course, that has cfdisk and sfdisk variants as well, but I was kind of hoping that if one was made to support this, they all would). IIRC that's the fdisk that everyone actually uses.
I had no idea that there was a GNU fdisk at all (though now you mention it, I see that there is).
And, yes, as soon as you have to shuffle out an existing partition, you are doomed or playing with fire (another reason I tend to use LVM, especially on high-availability systems).
LVM has some quite remarkable zones of suckitude, but the biggest -- the trainwreck called snapshots -- is easily avoided simply by never using them (though unfortunately pvmove(8) creates a snapshot so tumbles you briefly back into the valley of suck: I have had several pvmoves that deadlocked, blocking access to an important fs forever, and thus eventually blocking the whole system, though the last of these was some years ago). The only other suckitudes I'm aware of are the lack of barriers (thankfully now fixed) and the generally increased stack depths (and if that's a problem, you have bigger problems!)
Fedora Posted Dec 3, 2011 3:45 UTC (Sat) by jcm (subscriber, #18262) [Link]
None of the problems with LVM will get any better with fewer people using it :) And of course, the average "consumer" isn't going to experience problems with snapshots, so again they will not really notice that LVM is there.
Sorry, but this is NOT possible... Posted Nov 29, 2011 13:04 UTC (Tue) by khim (subscriber, #9252) [Link] Once again, I would advocate for simply turning it off if you don't want it. This is impossible. I personally never had problems with LVM because I understand what it does, why and how pretty well. I want to "turn it off" on hosed systems of some of my friends (because if someone, for example, dumped DVD image on top of /dev/sda it's much simpler to recover if you don't have an LVM installed) - and by that time it's much to late to try to disable it.
Fedora Posted Nov 29, 2011 16:03 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
And that actually won't be bad at all in maybe 10 years. After all, nobody has shed a tear about the death of /etc/raidtab.
Fedora Posted Nov 29, 2011 17:44 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
> So, why would I need to install LVM on my notebook ...
I don't know about you, but I use LVM on my netbook (EeePC) to provide full-disk encryption of the combined root filesystem and swap device with a single password (LVM on top of LUKS/dm-crypt). This is a standard configuration supported by the Debian installer.
I've also taken advantage of this arrangement in the past to adjust the filesystem alignment "live" (for better SSD performance), by adding an external USB drive to the LVM volume group, migrating the root filesystem & swap to that drive, and then repartitioning the internal drive and transferring the data back, all without any need to shut down the system or boot a separate "rescue" OS. LVM is a useful tool on any Linux system, whatever its disk layout may be. I would recommend using it even on single-filesystem setups, if only to make it easier to migrate to a new disk down the road.
Fedora Posted Nov 30, 2011 23:40 UTC (Wed) by zlynx (subscriber, #2285) [Link]
Migrating to a new disk. It's funny you say that.
LVM has done nothing but give me awful headaches when migrating disks. My traditional method is to bring up the new system and install a clean OS. Then with the old disk attached as a secondary drive get the data I want copied to the new system.
Fedora's LVM defaults always choose the same name for the volume group and volumes. LVM would then force me to jump through burning hoops of fire in order to properly mount the old disk since it had identical VG names. I can't even remember what I had to do but I do remember it was obnoxious.
Fedora Posted Dec 1, 2011 4:27 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Duplicate names don't really seem like much of a problem. The vgimportclone tool was specifically designed to support this case, automatically renaming the volume groups and changing the UUIDs to avoid conflicts.
You do need to make sure that the volume group holding the new filesystem(s) is detected first, so you don't boot from the old volume group, but that's not particularly difficult if you have access to an inexpensive USB/SATA adapter. You can always move the drive to an internal port, if desired, after any groups are renamed.
Alternatively, you can edit the filters in /etc/lvm/lvm.conf to ignore the extra drive during startup, and then change the filters back and use pvs to add it manually. Any of the symlinked udev device names will work, so you can filter the drives by hardware path, physical volume UUID, or device ID using the /dev/disk/by-* links. Or, if you prefer, you can set the filter to accept just the new physical volume(s) and ignore everything else.
Fedora Posted Dec 1, 2011 13:06 UTC (Thu) by sorpigal (subscriber, #36106) [Link]
> why would I need to install LVM on my notebook
The same reason I use LVM everywhere: if you always build it the same way it's easy to understand and remember. With LVM I can guarantee that I can always expand and shrink filesystems and swap devices around as I need it, no matter what FS is in use, and I always know how my layers are put together.
Never underestimate the cognitive burden that comes with choice. If things are put together only one way then everyone understands how every system works (or doesn't understand anything, which is a different problem). The basic disk+partition+filesystem is good partly because it's simple to understand but mostly because you can be sure everyone will be familiar with it. The problem with it is that with its simplicity comes a lack of power which I no longer find acceptable. LVM gives me the added flexibility when I want it and doesn't do significant harm when I don't; if everyone built every system on LVM then eventually it would be as well-understood as the simpler solutions while still giving me the power I sometimes need.
Fedora Posted Nov 25, 2011 7:48 UTC (Fri) by epa (subscriber, #39769) [Link]
If what you say is true, I would expect LVM to make common tasks easier. For example, with LVM it should be a simple matter to move your system from one hard disk to another. But so far my experience has been that this is not the case: it is much easier to manage your block devices without LVM than with it.
This is partly because I am more familiar with the old tools such as fdisk and mkfs, and less familiar with the LVM ones. This is the complaint of every old fart encountering a new way of doing things: it's not what I am familiar with, so it is more difficult (or even 'broken'). But given that with LVM you still have to understand fdisk and grub *as well* as knowing all the LVM commands and how to set up your initrd correctly, I'd argue that it has certainly made things more complex.
What I found is that LVM is not very discoverable. There didn't seem to be a command to just list all the logical volumes attached to the system and prompt whether to mount them. fdisk is user-friendly in comparison.
I don't doubt that for those managing serious storage arrays, LVM is invaluable. It's less clear that it should be the default choice every time you install Fedora (surely at least 90% of installations use a single hard disk). For me, it fails the test that easy things should be easy.
Fedora Posted Nov 25, 2011 16:50 UTC (Fri) by nix (subscriber, #2304) [Link] What I found is that LVM is not very discoverable. There didn't seem to be a command to just list all the logical volumes attached to the system and prompt whether to mount them.lvdisplay(8), or, if you'd like a less hard-to-read version, lvs(8). (No mount prompt though. That seems like a job for a script wrapped around lvs(8).)
Fedora Posted Dec 1, 2011 17:50 UTC (Thu) by jackb (subscriber, #41909) [Link] What I found is that LVM is not very discoverable. There didn't seem to be a command to just list all the logical volumes attached to the system and prompt whether to mount them. fdisk is user-friendly in comparison. I had the same experience. My first time trying out the tools figuring out the right sequence (pvcreate -> vgcreate -> lvcreate) only took a small amount of trial-and-error but figuring how to bring the logical volume online was one of the most frustrating tasks I can ever remember. Who think to themself, "The most obvious verb to describing creating a block device from some sequences of bits on some other block devices is change and the ability of the user to mount filesystems on said block device is an attribute of that device so let's call the command 'lvchange'"?
Fedora Posted Nov 26, 2011 0:16 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
LVM is PITA. It makes everything more complex and gives no benefits for 99% of users.
BTRFS already covers most of what I need from a modern filesystem with integrated volume management.
Fedora Posted Nov 26, 2011 0:26 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
<soapbox>
The vast majority of users don't need volume management at all.
even if you do something like dual booting to windows and need to resize the partitions between the two, volume management is not really of much help, you still need to resize the filesystem, and the same tools that do that will also resize the partitions without any need for volume management.
I have seen far more outages caused by people creating lots of partitions and then one of them filling up while the disk overall had lots of space left than I have of outages averted because only one partition filled up, and other partitions still had space left.
for desktop users, the drives are large enough nowdays that it's an unusual user who will have _any_ space problems if they go with 'one big partition'. laptop drives are not quite as big, but they are getting close (and volume management still doesn't help if you are trying to store 600G of stuff on a 500G drive)
There are _very_ few situations where using multiple partitions is a real benefit (appliances with fallback paritions for upgrading are one such situation, I'm not saying that there are none), and even fewer where volume management tools actually help.
Fedora Posted Nov 26, 2011 0:44 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Exactly.
I used to laugh at Windows users who set up several partitions (invariably with a small C: drive for system) and then frenetically try to clean up space on it while having many many gigabytes free on other partitions.
Then there's a question of RAIDs - LVM only has mirroring which doesn't really work that well (it resyncs completely every time after a reboot) and limited striping.
Now we have BTRFS that can do both, and at much higher level. Or MD tools which work on lower level but have much more features for real RAIDs.
PS: the only thing missing on MD RAIDs is TRIM support. I even had to write my own script to work around it: https://github.com/Cyberax/mdtrim/
Fedora Posted Nov 26, 2011 7:24 UTC (Sat) by anselm (subscriber, #2796) [Link] There are _very_ few situations where using multiple partitions is a real benefit (appliances with fallback paritions for upgrading are one such situation, I'm not saying that there are none), and even fewer where volume management tools actually help. In my Linux classes I teach people to make one partition for /home and one for the rest of the system. This makes it straightforward to upgrade or change one's Linux distribution (not everybody is running Debian, where upgrades are usually a cinch) without endangering the users' own data. It is a very common situation where using multiple partitions does have real benefits in my book, although it doesn't strictly require volume management. Having said that, one place where LVM has been decidedly useful for years as far as I'm concerned is snapshots for backups. With Btrfs around the corner, it is easy now to complain how LVM sucks, isn't necessary, etc. However, the LVM bashing that goes on around here does sound more than a little like picking on other kids at the playground knowing that your big brother is going to be around very soon. Btrfs may be a very good thing once it is production-ready, but I'm not holding my breath waiting to ditch my LVM+ext4 setups.
Fedora Posted Nov 26, 2011 9:57 UTC (Sat) by epa (subscriber, #39769) [Link]
I wasn't thinking of LVM vs btrfs, but just LVM versus plain ext4. For most users with a single disk, the simplest setup works fine and is easiest to manage when the time comes to upgrade.
Fedora Posted Nov 26, 2011 10:36 UTC (Sat) by anselm (subscriber, #2796) [Link] And as far as I'm concerned the »simplest setup« is one »system« partition and one partition for /home. Disk space is cheap.
Fedora Posted Nov 28, 2011 11:42 UTC (Mon) by james (subscriber, #1325) [Link]
May I suggest two system partitions, given the size of today's drives? That way you can update by installing to the system partition that isn't currently in use, and take your time getting it working the way you want.
Once you're ready to switch, you just put /home in the new /etc/fstab and update grub.
Quotes of the week Posted Nov 24, 2011 19:38 UTC (Thu) by jcm (subscriber, #18262) [Link]
We are the 1%. We, the people who read LWN are the 1% of the populous who want to choose to use Linux on our desktop (workstations). Designing GNOME for the 99% will result in a reduced userbase intersection somewhere of those who aren't hard core users and who haven't yet bought a Mac, Windows, or Android device. And please, let's stop the Occupy analogy now.
Quotes of the week Posted Dec 1, 2011 9:40 UTC (Thu) by ovitters (subscriber, #27950) [Link]
Goal of the project is different. I don't see how you'd get less people using something if the focus is different. I can see that existing users might not like it. Don't think a large share of the Ubuntu users read LWN or know of its existance.
I still see questions on how to replace Mutter with compiz. People who want that, more freedom to them. But such flexibility comes at a cost. I rather have a simplistic desktop, then extendable to meet your needs (e.g. Contacts/Documents applications will always remain to be simple; if you want something more advanced, install a more advanced program). Some things are not that easy to make extendable/flexible though (Mutter vs compiz).
the 99% was not regarding Occupy btw, it is a reference to a comment on Google Plus... though forgot which.
|
|||||||||||||