It appears you have an 8.4 database that isn't managed by pg_wrapper, and have installed 9.2 from Ubuntu packages and allowed it to create a pg_wrapper managed cluster in the default location, which isn't where you want the DB.
pg_upgradecluster from pg_wrapper isn't suitable for this, since you hand-initdb'd the old cluster.
If the 9.2 cluster doesn't have any data of value in it yet, drop it, destroying all its data:
pg_dropcluster 9.2 main
Then re-create it in the desired location. Assuming your mounted HD's root is /mydata, you'd:
pg_createcluster -d /mydata/pgdata_9.2_main 9.2 main
Now dump the old database and load it into the new one. Start both 8.4 and 9.1 on different ports; I'll assume 8.4 is on 5432 (default) and 9.2 is on 5433. Something like this should copy the dump from one directly into the other. Make sure you use the 9.1 versions of pg_dumpall and psql:
sudo -u postgres pg_dumpall -p 5432 | sudo -u postgres psql -p 5433
... but personally I'd do a pg_dumpall --globals-only using the 9.2 pg_dumpall against the 8.4 DB, followed by individual pg_dumps of each database in the old cluster (again using the 9.2 pg_dump). I'd then restore the globals dump followed by each individual dump into the new cluster.
Alternately, you can drop the pg_wrapper managed 9.2 cluster, not re-create it, and follow the instructions for pg_upgrade to do a binary upgrade from the 8.4 to the 9.2 DB. This will create a DB that is not managed by pg_wrapper. You can either convert it to be managed by pg_wrapper by moving and symlinking postgresql.conf and pg_hba.conf, or you can just manage it like you did 8.4, using your own init scripts.
Best Answer
You should always use
ashift=12today unless you have an overwhelmingly good reason not to.relatime=offmight save you a vanishingly small amount. Don't expect it to be measurable.xattr=sais important if you use extended attributes (e.g. SELinux) and you have a lot of tables and file opening/closing operations.logbias=throughputshould reduce your disk I/O volume, and it will help with SSD storage where there is no huge disconnect between bandwidth and latency like there is on spinning media.recordsize=8kwill ensure you don't have any RMW overheads. You'll have to decide whether the extra compression ratio achievable with largerrecordsizeis a net victory in your use case.You may find the slides from a lecture I gave on the subject useful.