Re: data=writeback - Mailing list pgsql-performance

From Priem, Alexander
Subject Re: data=writeback
Date
Msg-id 2A07EC2D0BC2774AAD6F74769F60D52A0832C9@ahmose.cict_ad.nl
Whole thread Raw
In response to data=writeback  ("Priem, Alexander" <ap@cict.nl>)
Responses Re: data=writeback
List pgsql-performance
> > > > LABEL=/usr/local/pgsql  /usr/local/pgsql      ext3
> > > > noatime,data=writeback  1 2
> > > > LABEL=/usr/local/pgsql  /usr/local/pgsql/wal  ext3
> > > > noatime,data=ordered    1 2
> > >
> > > The same label mounted on two different mount points is probably I
> > > typo?
> >
> >
> > No, the same label mounted on two different mount points is not a
> > typo. This is the way it is in my /etc/fstab.
> >
> > Note that I did not create this file myself, it was created by the
> > RedHat Enterprise Linux 3 ES installer. I created different partitions
> > for the data directory (/usr/local/pgsql) and the wal directory
> > (/usr/local/pgsql/wal) using the installer and this is how the
> > /etc/fstab file ended up.
> >
> > Why, is this bad? They use the same label, but use different mount
> > points? Can this cause problems?
>
> Mmm... how can the mounter distinguish the two partitions?
>
> Maybe I'm missing a concept here, but I thought labels must uniquely
identify partitions?
>
> Seems suspicious to me...
>
> Does it work? When you give just "mount" at the command line what output
do you get?
>
> Bye, Chris.

When I give "mount" at the command line, everything looks just fine :

/dev/sda2 on / type ext3 (rw,noatime,data=ordered)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/sda1 on /boot type ext3 (rw,noatime,data=ordered)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)
/dev/sdb1 on /usr/local/pgsql type ext3 (rw,noatime,data=writeback)
/dev/sda3 on /usr/local/pgsql/wal type ext3 (rw,noatime,data=ordered)

It looks like the labels are not really used, just the mount-points. Or
could this cause other problems I am not aware of? Everything seems to be
working just fine, for several months now...



pgsql-performance by date:

Previous
From: Cosimo Streppone
Date:
Subject: select count(*) on large tables
Next
From: Dennis Bjorklund
Date:
Subject: Re: select count(*) on large tables