On Tuesday 04 September 2007, Remy Blank wrote: > Alan McKinnon wrote: [snip] > > The only case I can think of that *requires* initramfs right now is > > booting off a raid device > > Strangely enough, I am currently booting from a software raid device, > so you don't need an initramfs for that either.
You have software compiled in the kernel, not as a module the, right? I would imagine you wouldn't need an initrd for that > >> And from what I remember, you can't resize a mounted ext3 > >> partition, > > > > balls. ext2online and resize2fs have been resizing ext3 partitions > > for ages. You can extend a mounted partition with ease and in > > safety. > > Have you ever tried pulling the plug while a resize operation was in > progress? I guess I'll have to test this myself, as my data is > valuable enough to me that I won't just believe what I read. An enlarge operation tends to be quite safe in my experience. At worst you get some new inodes that might not be accounted for, something that fsck will handle easily. A reduce might be a different case altogether. BUT, it's not an especially different operation to a defrag on Windows, and I have yet to see a Windows admin debate whether he should defrag or not based on the possibility of losing power halfway through... I can't comment too much on problems with reducing ext2/3, but I do reduce reiser3.6 filesystems often, once when the battery died, and it wasn't a problem when powered up. There was no feedback in the logs to speak of, so I assumed that the journal did what it was designed to do. This was in the first stages of the operation - moving blocks to the start of the volume, and I honestly have never done this test in the later stages - when inodes are removed from the superblock [snip] > > What you can't do, and to my knowledge no regular fs can do, is to > > *reduce* a mounted partition > > But who would want to do that? I always need *more* space, not less > ;-) emerged openoffice lately? :-) It pretty much always fails if you have <5G in /var/tmp/portage. On a laptop, that's 8% of my total disk space just sitting there free waiting for the day I emerge openoffice again. Umounting /var to reduce it is such a huge pita that I made /var/tmp/portage a separate volume and now reduce it at will. But true enough, especially on server, you will enlarge volumes much more often the reduce them [snip] > Anything special if I put the LVM over a software raid? Not in my experience. The only difficulty I ever had was persuading RHEL4 to install / like that - anaconda either doesn't support it or the button to click to do it is hidden in one of the magic cupboards at Hogwarts. But that's not a problem because: 1. this is gentoo 2. anaconda is these days less brain dead than it used to be Performance wise, it does well. The LVM and mdamd layers do their work in a fraction of the time it takes to get the data on/off the disk platters. In fact, Linux software usually outperforms most of those stupid el-cheapo we-say-it's-hardware-raid-but-actually-isn't raid controllers in low end hardware alan -- Optimists say the glass is half full, Pessimists say the glass is half empty, Developers say wtf is the glass twice as big as it needs to be? Alan McKinnon alan at linuxholdings dot co dot za +27 82, double three seven, one nine three five -- [EMAIL PROTECTED] mailing list
