Tim Robbins | 2 Jan 2003 10:44
Picon
Favicon

Re: mount_portalfs broken in 5.0-RC2

On Mon, Dec 30, 2002 at 10:51:20PM +0100, Michael Ranner wrote:

> After mounting the portalfs,
> 
> # cat /p/tcp
> 
> or
> 
> # cat /p/telnet
> 
> or
> 
> # cat /p/http
> 
> portalfs hangs instead of expected "cat: /p/telnet: No such file or directory"

I tried but failed to fix this. I think that the vnode locking in
portalfs is hosed. From memory, I think that portal_lookup() was
part of the problem. Try building a kernel with DEBUG_VFS_LOCKS and
watch for the warnings from portalfs.

Tim

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

Michael Ranner | 3 Jan 2003 21:20
Picon

Re: mount_portalfs broken in 5.0-RC2

Am Donnerstag, 2. Januar 2003 10:44 schrieb Tim Robbins:
> On Mon, Dec 30, 2002 at 10:51:20PM +0100, Michael Ranner wrote:
> > After mounting the portalfs,
> >
> > # cat /p/tcp
> >
> > portalfs hangs instead of expected "cat: /p/telnet: No such file or
> > directory"

Ok, I have to correct this. The first access to a file within /p
works as expected, but the second access locks the portalfs.

e.x.

# cat /p/tcp/1.2.3.4/110

works as expected for the first time an returns what you expect from
an pop3 server.

and

# cat /p/xyz

returns "cat: /p/xyz: No such file or directory" for the first time.

But if you try once again to access portalfs with /cat/tcp/1.2.3.4/110
or cat /p/xyz the portalfs hangs.

> I tried but failed to fix this. I think that the vnode locking in
> portalfs is hosed. From memory, I think that portal_lookup() was
(Continue reading)

trshfrahreh raheaeh | 4 Jan 2003 20:33
Picon
Favicon

(unknown)


_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

jamieclarcksong | 6 Jan 2003 06:10
Picon
Favicon

Examples of School Web Sites

Found some other school web sites that we may want to compare ours too!

http://bearcat.ubly.k12.mi.us/links/links.html

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

FreeBSD bugmaster | 6 Jan 2003 20:01
Picon
Favicon

Current problem reports assigned to you

Current FreeBSD problem reports
Critical problems
Serious problems
Non-critical problems

S  Submitted   Tracker     Resp.    Description
-------------------------------------------------------------------------------
a [2000/10/06] kern/21807  fs       [patches] Make System attribute correspon

1 problem total.

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

Tomas Pluskal | 11 Jan 2003 19:22
Picon

Re: seeking help to rewrite the msdos filesystem


Hello,

I have made a simple patch to enable clustering in msdosfs.
It is against 4-STABLE.

With this patch I get speed on my ZIP drive about 700KB/s (while before it
was about 80KB/s).

Could please someone review it ?

Thanks

Tomas

On Thu, 14 Nov 2002, Bruce Evans wrote:

> On Wed, 13 Nov 2002, Tomas Pluskal wrote:
>
> > > ...  Clustering increases the
> > > effective block size to 64K, which is large enough for most purposes,
> > > but mdosfs is missing the few lines of code needed to implement
> > > clustering...
> >
> > Could you please write a liitle more about those "missing few
> > lines of code" ? I think it is what I could do and what would help when
> > using ZIP drives and digital cameras etc..
>
> "grep -i cluster *.c" in code for other file systems.  cd9660 is simplest --
> it just has one cluster_read() instead of a bread().
(Continue reading)

David Schultz | 12 Jan 2003 16:47
Picon
Picon

Re: seeking help to rewrite the msdos filesystem

Thus spake Tomas Pluskal <plusik <at> pohoda.cz>:
> I have made a simple patch to enable clustering in msdosfs.
> It is against 4-STABLE.
> 
> With this patch I get speed on my ZIP drive about 700KB/s (while before it
> was about 80KB/s).
[...]
>  	if (ap->a_runp) {
> -		/*
> -		 * Sequential clusters should be counted here.
> -		 */
> -		*ap->a_runp = 0;
> +		int nblk;
> +
> +		nblk = (dep->de_FileSize >> bshift) - (lblkno + 1);
> +		if (nblk <= 0)
> +			*ap->a_runp = 0;
> +		else if (nblk >= (MAXBSIZE >> bshift))
> +			*ap->a_runp = (MAXBSIZE >> bshift) - 1;
> +		else
> +			*ap->a_runp = nblk;
>  	}

I'm not sure I understand what you're trying to do here.  Does
this work with files that are fragmented?  You appear to be
assuming that they are not.  Maybe you copied the code from the
cd9660 filesystem, which does not permit external fragmentation.
I think you need to use the cluster number returned by pcbmap() to
index into the FAT and extract the next cluster number, repeating
until you find that the next cluster is not contiguous, or until
(Continue reading)

Bruce Evans | 12 Jan 2003 22:00
Picon

Re: seeking help to rewrite the msdos filesystem

On Sun, 12 Jan 2003, David Schultz wrote:

> Thus spake Tomas Pluskal <plusik <at> pohoda.cz>:
> > I have made a simple patch to enable clustering in msdosfs.
> > It is against 4-STABLE.
> [...]
> >  	if (ap->a_runp) {
> > -		/*
> > -		 * Sequential clusters should be counted here.
> > -		 */
> > -		*ap->a_runp = 0;
> > +		int nblk;
> > +
> > +		nblk = (dep->de_FileSize >> bshift) - (lblkno + 1);
>
> I'm not sure I understand what you're trying to do here.  Does
> this work with files that are fragmented?  You appear to be
> assuming that they are not.  Maybe you copied the code from the
> cd9660 filesystem, which does not permit external fragmentation.

ISTR suggesting looking at cd9660 for examples of how to do clustering.
Unfortunately, it is too simple here.  The corresponding code in ufs
and ext2fs is quite complicated.

Bruce

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

(Continue reading)

Terry Lambert | 12 Jan 2003 22:11
Picon

Re: seeking help to rewrite the msdos filesystem

David Schultz wrote:
[ ... clustering patch ... ]
> I'm not sure I understand what you're trying to do here.  Does
> this work with files that are fragmented?  You appear to be
> assuming that they are not.  Maybe you copied the code from the
> cd9660 filesystem, which does not permit external fragmentation.
> I think you need to use the cluster number returned by pcbmap() to
> index into the FAT and extract the next cluster number, repeating
> until you find that the next cluster is not contiguous, or until
> you hit MAXBSIZE or the end of the file.

FWIW, I had the same question, but I haven't had time to really
stare at some FS instances from a working Windows box from the
FreeBSD side of things, to know how bad this really is, so I
thought that this might be on purpose.

I don't expect he'd ever see it at all, given his intended usage.

I think that it's not that bad (really), but will lose about 50%
of the performance improvement on a file that's partially fragged,
but still contains contiguous blocks in it.  On a generally fragged
file, you're not going to trigger the code at all.  I'm not really
sure a cluster can start at a non-boundary, anyway (this is what I
need to looks at examples to see), so it may be a total non-issue.

-- Terry

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message

(Continue reading)

Tomas Pluskal | 12 Jan 2003 22:52
Picon

Re: seeking help to rewrite the msdos filesystem


Thank you all for your comments.
I would like to state here, that I have no experience with
filesystem development at all (well, now I have a bit :)
You told me to look at the cd9660 code, so I did my best to do it like
it's in cd9660... I only partially understand what the code really does.

By the way, is there any documentation for these things anywhere ? I mean
it is quite hard to understand what pcbmap(), bread(), cluster_read() etc.
and their parameters really mean, just by reading the code...

If I understand it right, when I assume the file is not fragmented, it is
just a performance issue - it would make the FS slow on fragmented files,
but should not break anything. Is this correct?

If any of you could suggest a better solution (in a way that I could
understand it :), I can work on it.

Tomas

On Sun, 12 Jan 2003, Terry Lambert wrote:
>
> FWIW, I had the same question, but I haven't had time to really
> stare at some FS instances from a working Windows box from the
> FreeBSD side of things, to know how bad this really is, so I
> thought that this might be on purpose.
>
> I don't expect he'd ever see it at all, given his intended usage.
>
> I think that it's not that bad (really), but will lose about 50%
(Continue reading)


Gmane