From: Hubert Chan <hubert@uhoreg.ca>
To: reiserfs-list@namesys.com
Subject: Re: More on Hard Links
Date: Tue, 09 Dec 2003 13:48:44 -0500 [thread overview]
Message-ID: <87vfopyghf.fsf@uhoreg.ca> (raw)
In-Reply-To: 20031209052107.58404.qmail@web25009.mail.ukl.yahoo.com
>>>>> "Narcoleptic" == Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk> writes:
[...]
Narcoleptic> A. Symlinks:
Narcoleptic> ============
[...]
Narcoleptic> 2. By file (i.e. volume id and file id). File id is a
Narcoleptic> unique identifier for the file on the volume (eg. inode
Narcoleptic> number). Not sure if there is a way to uniquely identify a
Narcoleptic> volume reliably...
I don't think it's a good idea to classify these as symlinks. For one
thing, it's called a "symbolic" link, because the link contains a
symbol: a path name. Also, it works differently from regular
symlinks. IMHO, it would be better to give it another name. (This is
what I would call a "firmlink", and I think what Leo calls a "weak
link".)
[...]
Narcoleptic> 2. Linking to a file on a different ReiserX
Narcoleptic> volume.
Narcoleptic> ---------------------------------------------------
I believe the plan is to have Reiser5 be a distributed filesystem,
which will basically (AFAICT) solve all our problems and eliminates the
need for cross-ReiserFSx hard links. IMHO this is the better way to do
things, since a distributed filesystem will already take into account a
lot of problems that we have.
Not to say that you (or Leo) shouldn't pursue this idea. You may not
want to use the distributed stuff, or you may want to implement it as a
proof of concept to convince other FS maintainers to add it to their
FS, or etc.
[...]
Narcoleptic> My idea: Each volume can contain a "synchronized" copy of
Narcoleptic> the underlying file.
My first reaction: "Bwaa! Wasted space! Consistency problems!"
Wasted space, you're of course aware of. But then, the number of
hardlinks is probably not that large, so we won't have that many
duplicates.
Consistency problems you've dealt with, sort of. I'm a bit wary of
preventing the file from being changed if not all the involved volumes
are mounted. Also, if one volume dies and needs to be reformatted, or
removed, you need to have some way of recovering. It's hard to
differentiate that from the volume just being unmounted.
[...]
Narcoleptic> The principle of least privilege applies: if a file is on a
Narcoleptic> non-writable volume, no files synchronized with it are
Narcoleptic> modifiable.
So then you have the case where you have a file that's on a read-write
partition, has all the bits necessary for writing, but is read-only.
I'm not convinced this is the best thing to do. But if you must have
cross-filesystem hardlinks, I think this is what you must do.
Really, it's a compromise. I look at this situation and say: this is
why we can't have cross-filesystem hardlinks. Others may look at it
and say: I really want cross-filesystem hardlinks, and so this is what
I will do, which is reasonable, and doesn't completely suck.
[...]
Narcoleptic> 3. Linking to a file on a different non-ReiserX
Narcoleptic> volume.
Narcoleptic> -------------------------------------------------------
Narcoleptic> Not possible (because "file synchronization" management
Narcoleptic> code would be unique to ReiserX). User either has to use a
Narcoleptic> symlink or make a copy.
Well, if you implement it on ReiserFSx in a reasonably portable way,
you may be able to convince other FS maintainers to use it (if they
aren't completely opposed to the idea of cross-filesystem hardlinks).
--
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
next prev parent reply other threads:[~2003-12-09 18:48 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-04 5:58 Carrying Attributes too Far lrc1
2003-10-04 18:17 ` Alexander G. M. Smith
2003-10-04 20:10 ` Hubert Chan
2003-12-03 19:18 ` Hans Reiser
2003-12-05 0:30 ` lrc1
2003-12-05 3:58 ` A bold idea (Re: Carrying Attributes too Far) David Masover
2003-12-05 9:44 ` Heinz-Josef Claes
2003-12-05 14:00 ` David Masover
2003-12-05 16:37 ` Hubert Chan
2003-12-06 1:38 ` David Masover
2003-12-06 4:01 ` Hubert Chan
2003-12-06 17:40 ` David Masover
2003-12-06 22:41 ` lrc1
2003-12-07 1:18 ` carrying links too far? (was Re: A bold idea (Re: Carrying Attributes too Far)) David Masover
2003-12-07 2:26 ` Hubert Chan
2003-12-07 9:08 ` The danger of bad external links lrc1
2003-12-07 18:15 ` Hubert Chan
2003-12-07 13:18 ` carrying links too far? (was Re: A bold idea (Re: Carrying Attributes too Far)) lrc1
2003-12-07 16:17 ` David Masover
2003-12-07 18:25 ` Hubert Chan
2003-12-07 2:11 ` A bold idea (Re: Carrying Attributes too Far) Hubert Chan
2003-12-08 20:54 ` Boyd Waters
2003-12-09 8:03 ` Heinz-Josef Claes
2003-12-10 2:12 ` more about links (was Re: A bold idea (Re: Carrying Attributes too Far)) David Masover
2003-12-11 11:35 ` Heinz-Josef Claes
2003-12-05 13:16 ` More on Hard Links (was " Alexander G. M. Smith
2003-12-05 14:07 ` David Masover
2003-12-05 14:17 ` Nikita Danilov
2003-12-05 15:58 ` Hans Reiser
2003-12-05 16:18 ` Nikita Danilov
2003-12-06 1:50 ` Garbage collection for files (was Re: More on Hard Links (was A bold idea (Re: Carrying Attributes too Far))) David Masover
2003-12-07 3:27 ` Hans Reiser
2003-12-06 10:06 ` More on Hard Links (was A bold idea (Re: Carrying Attributes too Far)) Stewart Smith
2003-12-05 22:38 ` Alexander G. M. Smith
2003-12-06 1:54 ` David Masover
2003-12-06 15:31 ` Alexander G. M. Smith
2003-12-07 1:08 ` David Masover
2003-12-07 2:42 ` Alexander G. M. Smith
2003-12-09 5:21 ` More on Hard Links Narcoleptic Electron
2003-12-09 18:48 ` Hubert Chan [this message]
2003-12-09 19:52 ` Narcoleptic Electron
2003-12-09 21:31 ` Hubert Chan
2003-12-09 23:47 ` Narcoleptic Electron
2003-12-10 0:13 ` Narcoleptic Electron
2003-12-10 3:05 ` Hubert Chan
2004-01-22 21:15 ` Narcoleptic Electron
2003-12-10 2:53 ` Hubert Chan
2003-12-10 3:22 ` Religion and Hard Links (was Re: More on Hard Links) David Masover
2003-12-10 20:49 ` More on Hard Links Matt Stegman
2003-12-16 1:27 ` Hubert Chan
2003-12-10 2:44 ` David Masover
2003-12-05 5:27 ` Carrying Attributes too Far Hubert Chan
2003-12-05 12:38 ` Hans Reiser
2003-12-06 23:33 ` lrc1
2003-12-07 2:48 ` Hubert Chan
2003-12-07 17:08 ` Hans Reiser
[not found] ` <3FD0023D.5030500@ninja.dynup.net>
2003-12-07 6:37 ` Saved Re: A bold idea (Re: Carrying Attributes too Far) lrc1
2003-12-07 6:39 ` lrc1
-- strict thread matches above, loose matches on Subject: below --
2004-01-29 18:15 Fwd: Re: More on Hard Links Narcoleptic Electron
2004-01-29 18:18 ` Narcoleptic Electron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vfopyghf.fsf@uhoreg.ca \
--to=hubert@uhoreg.ca \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.