Hello, sorry for my delay ... On Tue, 12 Apr 2011, Anton Aylward wrote:
David Haller said the following on 04/12/2011 09:04 AM:
Let's say I'd use LVM, what if e.g. /dev/sde shows defects (seen in the SMART data). Can LVM show me what dirs and files(!) I have on the PV(s) on that probably soon-failing drive?
I think you are asking the wrong question.
Am I? What'd you do if you see a SMART failure for Sector 1234567 on device /dev/sdc? Wouldn't you want to replay the backup of the affected file _first_ (to another drive), so you have the file in duplicate again? Your backup _can_ fail too, and after Murphy, it will. c.f.: RAID: One more disk fails than can be recovered by the redundancy. -- Andreas Dau
If that drive is failing and and all files in any and all file systems in any and all LVs on any and all PVs on that drive are at risk. You don't need to know the individual file names.
Exactly my point! Which PVs and which LVs? Without RAID and LVM (and with ext2/3/4), you have _only one_ file (the one using that failed sector) affected until the drive actually dies. And (with debugfs) I can find out what file is affected. And of course, you replace the drive as soon as you can. But you still might want to reduplicate the (now) single ("current") instance of that file in the backup ASAP, so that there, again, is a redundancy between backup and live system. A file only in the backup is not a backup.
Thinking you have to backup/restore or move those files or file systems is "fixed partition" thinking. LVM thinking is tell the LVM system to stop using /dev/sde and to migrate the LVs (and hence the file systems and hence the files) to another PV.
And how do you know that the affected file will not be "migrated" to that "other" PV incorrectly? Will you get (and see) logs that that file caused an disk-IO-Error and that it is corrupted?
This is one reason why experienced users of LVM don't allocate all of the space to start with. We keep some around for snapshots and other contingencies, like this.
See above.
Yes, you have 'scrap space'. But the thing about LVM is that it does this at a lower level, so you don't have to worry about re-mounting and playing involved games with symlinks, partition tables and such
I don't need to. I choose to. And from an informed point of view, IMO.
LVM is more KISS than all those fixed size partitions.
Do you _REALLY_ understand LVM (and a possible underlying RAID) to the point to fix problems from a rescue system with - a hex-editor (e.g. vche or debug.com) - e2fsck [-b SUPERBLOCK] - debugfs (the latter two: or similar for other filesystems, if existant, else also with a hex-editor) I DO on my system!
If you really, really, really need it, LVM has the tools to tell you the mapping of a LV to disk sectors. Other file system tools can tell you what blocks in the file system a file uses. I saw on AIX tools that would tell you the answer to your question as it was posed, but then AIX *only* has LVM.
I still avoid it.
As far as Murphy goes * All Flesh is Grass (Isaiah 40:6) * All Hardware is Rust and Sand * All Software is BitRot
See above.
But for resilience and flexibility, using LVM beats out using fixed location and fixed size partitions.
I'm quite happy with my setup. I know and understand symlinks and 'mount --bind' intrinsically, with DOS-partitions down to the bit. And: symlinks work over NFS (once the NFS-stuff is mounted). ~10T of my stuff is in the other box, mounted via NFS. YMMV, of course! -dnh -- Tupperware wurde erfunden, damit man die Lebensmittel erst noch 14 Tage aufbewahren kann, bevor man sie wegwirft. -- Holger Hirschfeld -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org