Hi,
On Thu, 31 Aug 2000, Alexander Viro wrote:
> Go ahead, write it. IMNSHO it's going to be much more complicated and
> race-prone, but code talks. If you will manage to write it in clear and
> race-free way - fine. Frankly, I don't believe that it's doable.
It will be insofar more
[snip the plans for AFFS]
You know what? Try it. If your scheme is doable at all (I _very_ seriously
doubt it, since I've seen similar attempts on FAT-derived filesystems and
I remember very well what horror it was) it is doable with private locks.
Just take your locks always after the VFS is
Hi,
> > - get dentry foo
> > - get dentry baz
>
> How? OK, you've found block of baz. You know the name, all right.
Links are chained together and all point back to the original, so if you
remove the original, you have quite something to do with lots of links.
> Now
> you've got to do the
On Thu, 31 Aug 2000, J. Dow wrote:
> > being a jaded bastard I suspect that Commodore PHBs decided to save a
> > bit on floppy controller price and did it well after the initial design
>
> Comododo PHBs had nothing to do with it. And the Commododo floppy
> disk format is quite literally
Quoth a misinformed Alexander Viro re AFFS,
> As for the silliness of the OFS... I apologize for repeating the
> story if you know it already, but anyway: OFS looks awfully similar to
> Alto filesystem. With one crucial difference: Alto kept the header/footer
> equivalents in the sector framing.
On Thu, 31 Aug 2000, Roman Zippel wrote:
> Disclaimer: I know that the following doesn't match the current
> implementation, it's just how I would intuitively would do it:
>
> - get dentry foo
> - get dentry baz
How? OK, you've found block of baz. You know the name, all right. Now
you've got
Hi,
On Wed, 30 Aug 2000, Alexander Viro wrote:
> c) ->i_sem on pageout? When?
For 2.2.16:
filemap_write_page() <- filemap_swapout() <- try_to_swap_out() <- ... <-
swap_out() <- do_try_to_free_pages() <- kswapd()
filemap_write_page() takes i_sem and calls do_write_page(). What did I
Hi,
(Sorry for the previous empty mail, I was a bit too fast with sending and
couldn't stop it completly.)
On Wed, 30 Aug 2000, Alexander Viro wrote:
I concentrate on the most interesting part:
> As for AFFS directory format - fine, please describe the data
> manipulations required by
Alexander Viro wrote:
> On Wed, 30 Aug 2000, Roman Zippel wrote:
> > > What? You've proposed locking on pageout. If _that_ isn't the fast path...
> >
> > No, I suggested a lock (not necessarily the inode lock) during allocation
> > of indirect blocks (and defer truncation of them).
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hi,
On Wed, 30 Aug 2000, Alexander Viro wrote:
c) -i_sem on pageout? When?
For 2.2.16:
filemap_write_page() - filemap_swapout() - try_to_swap_out() - ... -
swap_out() - do_try_to_free_pages() - kswapd()
filemap_write_page() takes i_sem and calls do_write_page(). What did I
miss?
On Thu, 31 Aug 2000, Roman Zippel wrote:
Disclaimer: I know that the following doesn't match the current
implementation, it's just how I would intuitively would do it:
- get dentry foo
- get dentry baz
How? OK, you've found block of baz. You know the name, all right. Now
you've got to
On Thu, 31 Aug 2000, J. Dow wrote:
being a jaded bastard I suspect that Commodore PHBs decided to save a
bit on floppy controller price and did it well after the initial design
Comododo PHBs had nothing to do with it. And the Commododo floppy
disk format is quite literally unreadable
Hi,
- get dentry foo
- get dentry baz
How? OK, you've found block of baz. You know the name, all right.
Links are chained together and all point back to the original, so if you
remove the original, you have quite something to do with lots of links.
Now
you've got to do the full
[snip the plans for AFFS]
You know what? Try it. If your scheme is doable at all (I _very_ seriously
doubt it, since I've seen similar attempts on FAT-derived filesystems and
I remember very well what horror it was) it is doable with private locks.
Just take your locks always after the VFS is
On Wed, 30 Aug 2000, Roman Zippel wrote:
> > Your repeated claims of VFS becoming more multi-threaded in ways
> > that are not transparent to fs drivers wrt locking are false.
>
> For example the usage of inode lock changed pretty much and was partly
> replaced with the page lock? I can
Hi,
> Show me these removed locks. The only polite explanation I see is
> that you have serious reading comprehension problems. Let me say it once
> more, hopefully that will sink in:
>
> Your repeated claims of VFS becoming more multi-threaded in ways
> that are not transparent to
Hi,
> It sounds to me like different FSes have different needs. Maybe the best
> approach is to have two or three fs APIs, according to the needs of the
> fs.
No, having several fs API is a maintainance nightmare, I think that's
something everyone agrees on. What is needed is to modify the API
On Tue, 29 Aug 2000, Jeff V. Merkey wrote:
> I concur with this appraisal from Al Viro. Single threading the VFS is
> going backwards -- not a good idea.
It sounds to me like different FSes have different needs. Maybe the best
approach is to have two or three fs APIs, according to the needs
Hi,
Tony Mantler wrote:
> For those of you who would rather not have read through this entire email,
> here's the condensed version: VFS is inherintly a wrong-level API, QNX does
> it much better. Flame on. :)
VFS isn't really wrong, the problem is that it moved from an almost
single threaded
Hi,
> Yes? And it will become simpler if you will put each and every locking
> scheme into the API?
No, I didn't say that. I want the API to be less restrictive and make
the job for the fs a bit easier. IMO the current API is inconsistent
and/or incomplete and I'm still trying to find out what
On Wed, 30 Aug 2000, Albert D. Cahalan wrote:
> Ext2, XFS, Reiserfs, NWFS, and JFS need a multi-threaded VFS.
> Do we really need a screaming fast multi-threaded AFFS driver?
Erm... Roman seems to complain about VFS/VM not locking hard enough to
make protection of private fs data structures
Alexander Viro writes:
> On Wed, 30 Aug 2000, Roman Zippel wrote:
>> The point is: the thing I like about Linux is its simple interfaces, it's
>> the basic idea of unix - keep it simple. That is true for most parts - the
>> basic idea is simple and the real complexity is hidden behind it. But
>>
Hi,
Tony Mantler wrote:
For those of you who would rather not have read through this entire email,
here's the condensed version: VFS is inherintly a wrong-level API, QNX does
it much better. Flame on. :)
VFS isn't really wrong, the problem is that it moved from an almost
single threaded API
On Tue, 29 Aug 2000, David A. Gatwood wrote:
> Indeed, that's what a VFS layer should do -- abstract away all physical
> structure, inodes, etc., leaving only the file abstraction. I've read
It does. That leaves caring about the internal structures to fs - you
don't want fscked block bitmap
On Tue, 29 Aug 2000, Tony Mantler wrote:
> (Obligitory disclaimer: QNX is an embedded operating system, both it's
> architecture and target market is considerably different from Linux's)
>
> QNX's filesystem interfaces make it so painfully easy to write a filesystem
> that it puts everything
I concur with this appraisal from Al Viro. Single threading the VFS is
going backwards -- not a good idea.
:-)
Jeff
Alexander Viro wrote:
>
> On Wed, 30 Aug 2000, Roman Zippel wrote:
>
> > > > hfs. For example reading from a file might require a read from a btree
> > > > file (extent
On Wed, 30 Aug 2000, Roman Zippel wrote:
> > > hfs. For example reading from a file might require a read from a btree
> > > file (extent file), with what another file write can be busy with (e.g.
> > > reordering the btree nodes).
> >
> > And?
>
> The point is: the thing I like about Linux
At 8:09 PM -0500 8/29/2000, Roman Zippel wrote:
>So lets get back to the vfs interface
Yes, let's do that.
Every time I hear someone talking about implementing a filesystem, the
words "you are doomed" are usually to be heard somewhere along the lines.
Now, the bits on disk aren't usually the
Hi,
> > hfs. For example reading from a file might require a read from a btree
> > file (extent file), with what another file write can be busy with (e.g.
> > reordering the btree nodes).
>
> And?
The point is: the thing I like about Linux is its simple interfaces, it's
the basic idea of unix
On Tue, 29 Aug 2000, Roman Zippel wrote:
> hfs. For example reading from a file might require a read from a btree
> file (extent file), with what another file write can be busy with (e.g.
> reordering the btree nodes).
And?
> I really would prefer that a fs could sleep _and_ can use
Hi,
> Darnit, documentation on filesystem locking is there for purpose. First
> folks complain about its absence, then they don't bother to read the
> bloody thing once it is there. Furrfu...
It's great that it's there, but still doesn't tell you everything.
> Said that, handling of indirect
On Tue, 29 Aug 2000, Matthew Wilcox wrote:
> On Tue, Aug 29, 2000 at 06:08:04PM +0200, Roman Zippel wrote:
> > Anyway, I'm happy about any bug reports, that you can't reproduce with
> > hfs on a drive with 512 byte sectors (for that I still trying to fully
> > understand hfs btrees :-) ). I
On Tue, Aug 29, 2000 at 06:08:04PM +0200, Roman Zippel wrote:
> Anyway, I'm happy about any bug reports, that you can't reproduce with
> hfs on a drive with 512 byte sectors (for that I still trying to fully
> understand hfs btrees :-) ). I don't think this patch should be included
last time i
Hi,
Here is a patch for anyone who needs to access HFS on e.g. an MO drive.
It's only for 2.2.16, but I was able to do that as part of my job as we
need that functionality. Anyway, I've read also a bit through HFS+ spec
and IMO basically most of the current hfs needs to rewritten for 2.4,
e.g.
36 matches
Mail list logo
