initdb and data directories with lost+found

Looks like initdb is just a tad too strict when checking to make sure
the data directory is empty. Yesterday I created a new data directory
as it's own filesystem (linux ext2), it includes a lost+found directory.
To initdb this means that the directory is no longer empty and it refuses
to run. While I hope to never need lost+found, e2fsck will recreate it
if it is missing (it is safer to create it when the filesystem is stable).

My quick fix to allow the lost+found directory:
--- src/bin/initdb/initdb.sh 2001/03/13 21:37:15 1.122
+++ src/bin/initdb/initdb.sh 2001/03/22 15:45:46
@@ -402,7 +402,7 @@

# find out if directory is empty
pgdata_contents=`ls -A "$PGDATA" 2>/dev/null`
-if [ x"$pgdata_contents" != x ]
+if [ x"$pgdata_contents" != x -a "$pgdata_contents" != "lost+found" ]
then
(
echo "$CMDNAME: The directory $PGDATA exists but is not empty."

This fix works for ext2, but will (obviously) not work if the filesystem
uses something other than "lost+found".

Steve Stock
steve(at)technolope(dot)org

Steve Stock <steve(at)technolope(dot)org> writes:
> --- src/bin/initdb/initdb.sh 2001/03/13 21:37:15 1.122
> +++ src/bin/initdb/initdb.sh 2001/03/22 15:45:46
> @@ -402,7 +402,7 @@

> # find out if directory is empty
> pgdata_contents=`ls -A "$PGDATA" 2>/dev/null`
> -if [ x"$pgdata_contents" != x ]
> +if [ x"$pgdata_contents" != x -a "$pgdata_contents" != "lost+found" ]
> then
> (
> echo "$CMDNAME: The directory $PGDATA exists but is not empty."

> This fix works for ext2, but will (obviously) not work if the filesystem
> uses something other than "lost+found".

AFAIK that name is universally used. Seems like a reasonable change to
me; Peter, do you agree?

regards, tom lane

Steve Stock writes:

> Looks like initdb is just a tad too strict when checking to make sure
> the data directory is empty. Yesterday I created a new data directory
> as it's own filesystem (linux ext2), it includes a lost+found directory.

It is never a good idea to let initdb loose on a directory that might
possibly have some other purpose, including that of being the root
directory of an ext2 partition. Initdb or the database system can do
anything they want in that directory, so it's not good to save lost blocks
somewhere in the middle, even if chances are low you need them. I say,
create a subdirectory.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

On Thu, Mar 22, 2001 at 06:16:03PM +0100, Peter Eisentraut wrote:
> It is never a good idea to let initdb loose on a directory that might
> possibly have some other purpose, including that of being the root
> directory of an ext2 partition. Initdb or the database system can do
> anything they want in that directory, so it's not good to save lost blocks
> somewhere in the middle, even if chances are low you need them. I say,
> create a subdirectory.

While I agree that the PGDATA directory shouldn't be used by anything
save postgres, I don't think that lost+found constitutes another use of
the directory. The only way that a conflict could occur is if postgres
used the lost+found directory, something I that don't expect will occur.

Side note, the reason that I ran into this in the first place is because
I'm toying with multiple data directories each on their own logical volume.
For the directory structure I'd prefer something like postgres/data[123]
rather than postgres/data[123]/data or postgres[123]/data.

Steve Stock
steve(at)technolope(dot)org