Re: Ignore lost+found when checking if a directory is empty

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brian Pitts <bdp(at)uga(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ignore lost+found when checking if a directory is empty
Date: 2011-08-09 20:28:29
Message-ID: 12168.1312921709@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Brian Pitts <bdp(at)uga(dot)edu> writes:
> When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because it sees the
> lost+found directory that mke2fs created and assumes the PGDATA directory is already in use for something other than PostgreSQL.
> Attached is a patch against master which will cause a directory that contains only lost+found to still be treated as empty.

This has been proposed before, and rejected before, on the grounds that
you shouldn't be using a mount-point directory as a data directory
anyway. Better practice is to make a postgres-owned directory just
underneath the mount point. A couple of reasons for that are:

1. Mount-point directories should be owned by root, never by an
unprivileged account such as postgres. IIRC there are good security
reasons for this practice, though I don't recall all the details right
now.

2. Keeping the data directory one level down ensures a clean failure if
the disk is for some reason not mounted when Postgres starts, or goes
offline later. Otherwise, particularly if you're using a start script
that will automatically try an initdb, you might end up with some data
files on the / volume underneath where the mount point should have been.
This is sure to lead to serious problems when the disk does come back
online. There's at least one horror story in our archives from someone
who had an auto-initdb startup script and one day his NFS disk was a few
seconds slow to mount...

> This was previously proposed in 2001; see http://archives.postgresql.org/pgsql-hackers/2001-03/msg01194.php

It's been discussed more recently than that, I believe.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-08-09 20:32:35 Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Previous Message Jeff Davis 2011-08-09 20:08:03 Re: Ignore lost+found when checking if a directory is empty