On October 26, 2005 10:02 am, John Gilmore wrote:
> Actually, when I had first read about file-as-directory, I had assumed that
> the content was either dynamically generated from the on-disk metadata
> (like uid, gid, etc) or stored as a "sideband" type stream in the file
> itself, like some of th
On Wed, 26 Oct 2005 17:02:06 +, John Gilmore <[EMAIL PROTECTED]> said:
> On Wednesday 26 October 2005 22:40, Nate Diller wrote:
>> File-as-Directory
>> The issue with file-as-directory (FaD) is that it removes the Acyclic
>> property of the namespace graph.
More precisely, it removes an easy
On Wednesday 26 October 2005 22:40, Nate Diller wrote:
> File-as-Directory
> The issue with file-as-directory (FaD) is that it removes the Acyclic
> property of the namespace graph. This is because anything which contains
> file data can be hard-linked, even if that item is also a directory. It
On 10/26/05, Chester R. Hosey <[EMAIL PROTECTED]> wrote:
> Peter van Hardenberg wrote:
> > Although I freely acknowledge my inexperience, I believe the real problems
> are
> > related to graph traversal algorithms. Linus has commented on the obvious
>
> > hardlink issues. I imagine there are more
Nate Diller wrote:
>On 10/26/05, Peter van Hardenberg <[EMAIL PROTECTED]> wrote:
>
>
>>On October 26, 2005 05:44 am, you wrote:
>>
>>
>
>
>
>>Also: I still have not been able to USE files as directories. Yes, I can
>>reach
>>file//, but that is only one special case. I can crash th
On 10/26/05, Peter van Hardenberg <[EMAIL PROTECTED]> wrote:
> On October 26, 2005 05:44 am, you wrote:
> Also: I still have not been able to USE files as directories. Yes, I can
> reach
> file//, but that is only one special case. I can crash things like it
> was
> going out of style by p
I am too an amateur FS geek.
A link you might like to look at.
http://www.geocities.com/ravikiran_uvs/
It contains a Simple file system. That has helped me, and may be of
interest to you.
On Tue, 2005-10-25 at 15:58 -0700, Peter van Hardenberg wrote:
> Hello all,
>
> I'm a student at the Univers
Chester R. Hosey wrote:
Peter van Hardenberg wrote:
Although I freely acknowledge my inexperience, I believe the real problems are
related to graph traversal algorithms. Linus has commented on the obvious
hardlink issues. I imagine there are more gremlins lurking in the shadows on
this one. G
Please remember that the idea of the plugin is that it is selectively
used on a few files.
Nate, please comment on your notion of having list all functionality,
and how allowing cycles could be ok under such a scenario.
Hans
Chester R. Hosey wrote:
>Peter van Hardenberg wrote:
>
>
>>Although I freely acknowledge my inexperience, I believe the real problems
>>are
>>related to graph
Hi,
I've been using reiserfs for several years now and it's been choice
number one for me; I'll probably switch to reiser4 once it's in the
main kernel.
on my home file server machine, one hard drive (120GB) reports 80 GB used, but I have no idea how and where it's used.
df -h reports 80GB used
Peter van Hardenberg wrote:
> Although I freely acknowledge my inexperience, I believe the real problems
> are
> related to graph traversal algorithms. Linus has commented on the obvious
> hardlink issues. I imagine there are more gremlins lurking in the shadows on
> this one. Garbage collector
On 10/25/05, Ingo Bormuth <[EMAIL PROTECTED]> wrote:
> I agree, real backups are the major weappon against classical data loss due
> to hardware failure.
> Other quite anoying and common causes for data loss are accidentally deleted,
> overwritten or modified files. A _simple_ versioning plugin wou
On 10/25/05, Sander <[EMAIL PROTECTED]> wrote:
> That will kill performance badly. First of all the two read/writes
> needed, and second because you have to seek from one end to the disk to
> the other every time you read/write something.
Kill it worse for writes than a filesytem without wandering
On 10/25/05, Hans Reiser <[EMAIL PROTECTED]> wrote:
> This would not be (at least in theory) useful for RAID devices, but for
> a user with a single disk drive, it might be useful to have a plugin
> that creates two (or N) copies, and tries to allocate the two copies at
> opposite ends of the disk.
On October 26, 2005 05:44 am, you wrote:
> Also take a look at the part of a (record-breakingly long?) thread "file
> as a directory" on this list (also copied to lkml) near and after:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/0044.html
>
> There, I suggested that file selection shou
On Tue, 2005-10-25 at 09:25 +0200, Sander wrote:
> Hans Reiser wrote (ao):
> > This would not be (at least in theory) useful for RAID devices, but for
> > a user with a single disk drive, it might be useful to have a plugin
> > that creates two (or N) copies, and tries to allocate the two copies at
Hans Reiser wrote:
Edward Shishkin wrote:
Hans Reiser wrote:
John Gilmore wrote:
So the first beta of compression will only have the option to
control it at mkfs time?
It should be explained that on the first flush to disk of a new file the
default compress plug
Hubert Chan wrote:
On Tue, 25 Oct 2005 17:04:55 -0700, Peter van Hardenberg <[EMAIL PROTECTED]>
said:
I envision creating a simple shell in a scripting language which will
operate on an XML representation of the filesystem which maps, in the
simple case, directories and files such that simp
19 matches
Mail list logo
