sed on
tradition, are more convincing.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
benefits from late
allocation: one that creates a lot more virtual memory than it ever
touches. For example, a sparse array. Or am I missing something?
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
--
To unsubscribe from this
thinks it's entitled to and it
can reduce its memory footprint to improve its speed. It can even check
whether an access to readahead data caused a page fault; if so, it knows
reading ahead is actually making things worse and therefore reduce
readahead until the page faults stop happening.
g the medium must be bad. But there
are various algorithms for deciding when to reassign a sector, so it might
not too.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
--
To unsubscribe from this list: send the line "unsub
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote on 01/18/2008 07:08:30 AM:
> Bryan Henderson wrote:
> >
> > We weren't actually talking about writing out the cache. While that
was
> > part of an earlier thread which ultimately conceded that disk drives
its own power is failing at the same time, which makes the
integrity at the disk level moot (or even undesirable, as you'd rather
write a bad sector than a good one with the wrong data).
--
Bryan Henderson IBM Almaden Research Center
San Jose CA
"Daniel Phillips" <[EMAIL PROTECTED]> wrote on 01/16/2008 06:02:50 PM:
> On Jan 16, 2008 2:06 PM, Bryan Henderson <[EMAIL PROTECTED]> wrote:
> > >The "disk motor as a generator" tale may not be purely folklore. When
> > >an IDE drive is no
g the
performance of writeback caching.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
>the
>maintainers of util-linux have well versed autotool people at their
disposal,
>so i really dont see this as being worrisome.
As long as that is true, I agree that the fact that so many autotool
packages don't work well is irrelevant.
However, I think the difficulty of using autotools (I
>i dont see how blaming autotools for other people's misuse is relevant
Here's how other people's misuse of the tool can be relevant to the choice
of the tool: some tools are easier to use right than others. Probably the
easiest thing to use right is the system you designed and built yourself.
>If your only purpose is to try generate a defensive patent, then just
>dumping the idea in the public domain serves the same purpose, probably
>better.
>
>I have a few patents, some of which are defensive. That has not prevented
>the USPTO issuing quite a few patents that are in clear violation of
escribed, wildly successful, that means
users are willing to tolerate this level of breakage, so it could be used
for versioning too.
But I think I'd rather see a truly hidden directory for this (visible only
when looked up explicitly).
--
Bryan Henderson IBM Alm
w the dot files by default, having been
burned too many times by invisible files).
I assume NetApp flags the directory specially so that a POSIX directory
read doesn't get it. I've seen that done elsewhere.
The same thing, by the way, is possible with Jack's filename:version idea,
and
feeling that
I compromised in order not to involve the kernel.
Of course, if you want to do it with snapshots and COW, you'll have to ask
where in the kernel to put that, but that's not a file versioning
question; it's the larger snapshot question.
--
Bryan Henderson
ble inode number might fall in that
category.
I fully agree that much effort should be put into making inode numbers
work the way POSIX demands, but I also know that that sometimes requires
more than just writing some code.
--
Bryan Henderson San Jose Californi
hem unreliable (or unscalable) in the same ways as an NFS
server.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
>Have you looked at how we're dealing with this in NFSv4?
No.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
r open when the
filesystem driver has said the entire operation is complete.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
>I don't see how the following is tortured:
>
>enum {
> PNODE_MEMBER_VFS = 0x01,
> PNODE_SLAVE_VFS = 0x02
>};
Only because it's using a facility that's supposed to be for enumerated
types for something that isn't. If it were a true enumerated type, the
codes for the enumeration
>If it's really enumerated data types, that's fine, but this example was
>about bitfield masks.
Ah. In that case, enum is a pretty tortured way to declare it, though it
does have the practical advantages over define that have been mentioned
because the syntax is more rigorous.
The proper way
I wasn't aware anyone preferred defines to enums for declaring enumerated
data types. The practical advantages of enums are slight, but as far as I
know, the practical advantages of defines are zero. Isn't the only
argument for defines, "that's what I'm used to."?
Two advantages of the enum d
he and generic writer).
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
arge-block filesystem driver does the nopage thing, and does in fact
fill in files unnecessarily in this scenario. :-( The driver for the
same filesystems on AIX does not, though. It has the write protection
thing.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA
How it can be used? Well, say it you've mounted JFS on /usr/local
>% mount -t jfsmeta none /mnt -o jfsroot=/usr/local
>% ls /mnt
>stats control bootcode whatever_I_bloody_want
>% cat /mnt/stats
>master is on /usr/local
>fragmentation = 5%
>696942 reads, yodda, yodda
>% echo "defrag 69 whatev
>If we can truly go for label based mounting
>and lilo'ing this would solve the problem.
>From a layering point of view, it makes a lot more sense to
me for the label (or signature or whatever) for this purpose
to be in the partition table than inside the filesystem. The
parts of the system th
25 matches
Mail list logo
