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
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
file
"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
Jan
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]