Messages in this thread | | | From | Heinz Mauelshagen <> | Subject | Re: (reiserfs) Re: LVM / Filesystems / High availability | Date | Sat, 27 Jun 1998 14:21:25 METDST |
| |
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU> > Date: Fri, 26 Jun 1998 16:13:12 -0400
> A block-device LVM can do this, but at the cost of being very > inefficient when you need retire a physical device which happens to be > located in the middle of a filesystem, a lot more block copying needs to > be done than if you let the filesystem simply handle it.
No matter which software user (filesystem, database etc.) is actually performing on a LVM device, we get use of _TRANSPARENTLY_ retiring whatever sized disk (sure, we have to have a free one of at least the same size), because the logical adress space _NEVER_ changes while moving physical extends around to retire disk(s)!!!
BTW: please have a look at http://www.msede.com/linux/lvm/ for terms and features of the LVM to clearify things
So, please let's stop the discussion: "let's do it in the filesystem / no, let's do it in the device layer (LVM)"
Discussion about extending FSes at the _END_ and reducing them _FROM_ the end allready started AFAIK (this one should indead go to linux-fsdevel).
I'ld always prefer mass storage admin flexibility for _ALL_ mass storage software users (maybe loosing some performance), because we all don't retire disks all day, do we?!
BTW: LVM is a large scalabillity issue, not a desktop one
Regards, Heinz
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Systemmanagement Entwicklungsbereich 2 Deutsche Telekom AG Entwicklungszentrum Darmstadt Heinz Mauelshagen Otto-Roehm-Strasse 71c Postfach 10 05 41 mge@ez-darmstadt.telekom.de 64205 Darmstadt Germany +49 6151 886-425 FAX-386 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |