DragonFly BSD
DragonFly kernel List (threaded) for 2011-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: HAMMER2 design in progress - 1-2 year time frame

From: Jan Lentfer <Jan.Lentfer@xxxxxx>
Date: Fri, 30 Dec 2011 20:14:00 +0100

Am 06.07.2011 09:14, schrieb Sascha Wildner:
> On Sun, 03 Jul 2011 09:12:43 +0200, Steve O'Hara-Smith
> <steve@sohara.org> wrote:
>> On Sat, 2 Jul 2011 23:40:53 -0700 (PDT)
>> Matthew Dillon <dillon@apollo.backplane.com> wrote:
>>> I'll continue to think about how at least a small number of hardlinks
>>> could be implemented without turning already complex cluster
>>> algorithms into a disaster zone. So far I'm drawing a blank.
>> There are plenty of filesystems that support hard links around, but
>> hardly any that support multi-master clustering. I would say that hard
>> links are a small price to pay for multi-master clustering.
> The question is too how many users will use the multi-master feature vs.
> how many users will be using it as a generic file system on their single
> machine. Don't know what the answer is to that one, though.
> The issue with hard links is that they are part of POSIX and stuff out
> in the wild will just use it and expect it to work like on most of the
> other file systems.
> We've already had a case where stuff (gdb it was I think) would
> configure wrongly because hammer would not update file access times on
> read (which is specified in POSIX too). If there are issues with the
> hard links missing, I guess they would be along the same lines.
> But I have no idea how big a problem it will be in practice.

A conversation on #postgresql made me come back to this thread. E.g. 
PostgreSQL is a software that 100% depends on hardlinks, according to this:

17:35 < hlan> the file system I use for my postgres data storage does 
not support hard links... and it just blew up with "LOG:  could not link 
               "pg_xlog/xlogtemp.11066" to 
"pg_xlog/000000010000000000000001" (initialization of log file 0, 
segment 1): Function not implemented"
17:36 < hlan> why would you rely on hard links? seriously... :/
17:36 < hlan> are there some way to disable this behavior?
17:42 < mst> hlan: because hard links are widely available and atomic
17:42 < mst> hlan: I suggest you ask your sysadmin for a working file system
17:49 < mastermind> hlan: what kind of strange filesystem do you have there?
17:49 < hlan> mst: I wrote the file system and I am the sysadmin. I 
didn't want to support hard links because they are obscure/hardly used 
and easily
               creates confusion due to them being non transparent... 
and why use them when there are symlinks?
17:49 < hlan> postgres is the first software I actually had problems with
17:50 < mst> hlan: they're not obscure, they're heavily used
17:50 < mst> hlan: atomic 'mv' is impossible without them
17:50 < mst> hlan: if you don't have that, a massive percentage of *n?x 
standard approaches are impossible
17:50 < hlan> I guess I have to implement hard links then


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]