On Sat, 25 Feb 2006, Peter Foldiak wrote:
> "sub-file" corresponding to a key-range. Writing a chapter should change the
> book that the chapter is part of. That is what would make it really valuable.
> Of course it would have all sorts of implications (e.g. for metadata for each
> part) that need
On Sat, 25 Feb 2006, Maciej Soltysiak wrote:
> Code files, DNS zones, configuration files, HTML code. We are still
> dealing with lots of text files today.
You say it like it's a bad thing, but in truth I suspect
people often deal with text files because they're EASY
to manipulate through script
On Tue, 21 Jun 2005, David Masover wrote:
> The point is, this was in the kernel for quite awhile, and it was so
> ugly that someone would rather be fucked with a chainsaw. If something
> that bad can make it in the kernel and stay for awhile because it
> worked, and no one wanted to replace it
On Thu, 26 Aug 2004, Linus Torvalds wrote:
> So "/tmp/bash" is _not_ two different things. It is _one_ entity, that
> contains both a standard data stream (the "file" part) _and_ pointers to
> other named streams (the "directory" part).
OK, that makes sense.
> Hey, think of it as a wave-partic
On Thu, 26 Aug 2004, Linus Torvalds wrote:
> On Thu, 26 Aug 2004, Rik van Riel wrote:
> >
> > So you'd have both a file and a directory that just happen
> > to have the same name ? How would this work in the dcache?
>
> There would be only one entry in th
On Thu, 26 Aug 2004, Linus Torvalds wrote:
> For example, you _could_ probably (but hey, maybe "tar" tries to strip
> slashes off the end of filenames, so this might not work due to silly
> reasons like that) back up a compound file with
>
> tar cvf file.tar file file/
So you'd have both a
On Thu, 26 Aug 2004, Jamie Lokier wrote:
> Christophe Saout wrote:
> > And if you read test.compound (the main stream) you get a special format
> > that contains all the components. You can copy that single stream of
> > bytes to another (reiser4) fs and then access test.compound/test.txt
> > agai
On Thu, 26 Aug 2004, Denis Vlasenko wrote:
> > I like cat < a > b. You can keep your progress.
>
> cat b does not preserve following file properties even on standard
> UNIX filesystems: name,owner,group,permissions.
Losing permissions is one thing. Annoying, mostly.
However, actual losing file
On Sun, 1 Aug 2004, Hans Reiser wrote:
> You can think of this as chroot on steroids.
Sounds like what you want is pretty much the namespace stuff
that has been in the kernel since the early 2.4 days.
No need to replicate VFS functionality inside the filesystem.
--
"Debugging is twice as hard
On Mon, 28 Jan 2002, Linus Torvalds wrote:
> On Mon, 28 Jan 2002, Rik van Riel wrote:
> >
> > I'd be interested to know exactly how much overhead -rmap is
> > causing for both page faults and fork (but I'm sure one of
> > the regular benchmarkers can figure
On Mon, 28 Jan 2002, Linus Torvalds wrote:
> I am, for example, very interested to see if Rik can get the overhead of
> the rmap stuff down low enough that it's not a noticeable hit under
> non-VM-pressure. I'm looking at the issue of doing COW on the page tables
> (which really is a separate iss
11 matches
Mail list logo