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
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 to
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
I
On Thu, 26 Aug 2004, Denis Vlasenko wrote:
I like cat a b. You can keep your progress.
cat a 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 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
again.
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 file
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 the dcache. The lookup will select
whether
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-particle
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:
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
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 that one out while I fix
the RSS limit stuff
11 matches
Mail list logo
