Subject | database location [WAS permission denied] |
---|---|
Author | Mike Dewhirst |
Post date | 2005-04-19T09:11:18Z |
Jason Dodson wrote:
OK - but isn't a firebird database a static-ish single file? I can
imagine lots of stuff happening within that file but the OS surely
wouldn't be rewriting it every few seconds. I suppose it extends itself
every now and then as it adds pages.
on the linux filesystem?
Hang-on, if /var is located on its own disk as you say for busy servers,
then where should the database be located - on that (expected to be)
busiest disk as well?
I can appreciate that it doesn't matter for small systems but I think I
(perhaps) ought to create a new top-level directory so that I can one
day add a super-fast disk to the system and dedicate it to the database.
What do you think?
Mike
> The idea being that you generally don't have a filesystem "defragger". AThanks Jason
> unix filesystem is different then that of, say Windows.
>
> User tools, system libraries and such will never really change. If they
> do, it SHOULDNT be that often. So they go into a part of the
> filesystem/disk that is optimized (or should be) for this kind of
> operation. And with that, lots or creating/deleting/writing files can
> really affect your file system performance.
>
> /var is part of the filesystem (and generally coordinated the same on
> the disk) that is meant for heavy IO. On bigger servers, this is where
> you would have your most speedy, high-end disk. When it is part of the
> same physical disk as the rest of the system, it at least is the only
> place that should ever have fragmentation... and with that, the only
> place that fragmentation is maintained... So it is quick and efficient.
OK - but isn't a firebird database a static-ish single file? I can
imagine lots of stuff happening within that file but the OS surely
wouldn't be rewriting it every few seconds. I suppose it extends itself
every now and then as it adds pages.
> /tmp is usually a symlink to /var/tmp. Also, just being under /varOK - that means I can evolve my own "standard" for locating a database
> doesn't imply that it is free for the world to grab at. Mailboxes under
> /var/spool/mail for instance only allow the owner of the mailbox and
> mail to access them. System logs under /var/log are only readable by root.
>
> Anyway, like Helen said, it probably really doesn't matter :|
on the linux filesystem?
Hang-on, if /var is located on its own disk as you say for busy servers,
then where should the database be located - on that (expected to be)
busiest disk as well?
I can appreciate that it doesn't matter for small systems but I think I
(perhaps) ought to create a new top-level directory so that I can one
day add a super-fast disk to the system and dedicate it to the database.
What do you think?
Mike
> Jason
>
>
> Helen Borrie wrote:
>
>>At 05:17 PM 17/04/2005 +1000, you wrote:
>>
>>
>>
>>>>3) it is not a Good Thing (TM) to grant other users privileges in root's
>>>>home directory. I suggest you create a filesystem tree called /data (or
>>>>similar) and make that the firebird user's "patch".
>>>
>>>Will do. Or at least I'll ask Jason why it would be better to use /var.
>>
>>
>>It doesn't matter what it's called. But /var is a special-purpose
>>filesystem on *x versions that use it, generally for storing program
>>variable data. I suppose you could think of a database files as program
>>variable data. :-) I'm more for considering permissions. A database file
>>is "private space" - it should be accessible only to those who need to
>>access it as a file.
>>
>>btw, it makes a lot of sense to create a firebird group, of which the
>>firebird user and (where required) the database users. Then you can give
>>the firebird user owner privs in the spaces where it needs them, and give
>>group privs to the spaces where owner privs are not required.
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>