Menu
▾
▴
njbfs-devel — Development List - (High Traffic)
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(2) |
Feb
(60) |
Mar
(9) |
Apr
(3) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
(24) |
Oct
(2) |
Nov
|
Dec
(1) |
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ben O. <be...@gi...> - 2002-02-24 00:12:46
|
On Sat, 23 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Ben Osheroff wrote: > Then I can update my local sources and get ready to merge your changes wi= th > my code. Ok, this is gonna be a motherfucker of a merge; I've shuffled around a few things to different files, too... although I managed to keep most of my changes in a couple of seperate files, njbfs_cache.c and njbfs_dir.c I'm gonna check in to the main branch (I did this work seperate from my other work), so let me know how the merge goes. -ben > The code must be tested, and merged with your changes, so don't expect > things too soon. I expect system lockups will be gone then, because I sta= rted > to implement the interoperability between the device driver and the file > system. Ok, cool. > You are unemployed Ben? I was lucky and found a new job. But since my new= job > begins at 15 March or 1 April, I have lot of time for njbfs now. Yup, no job. I am made of time and carbon right now. |
|
From: Danish Q. <dx...@nj...> - 2002-02-23 19:13:35
|
On Sat, 23 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Ben Osheroff wrote: > > It uses an internal njbfs_fattr-based cache which is pretty nice; files= in > > different directories share the same core structure. > > Cool. Yes, definitely a good idea. > > Do you want to see the code before I check it in? Or should I just fin= ish > > up and check in? > > I would suggest just let things roll. Check in the files if they pass you= r > tests. Yeah, just check them back into your branch, or even into the main branch if you want. BTW, I never asked what distro and setup you were using for devving this thing. Speaking of the njb usb ops, are we confident that the old nomad driver that Jorg built this upon, has the latest operation table from the protocol by John Mechelas? IIRC, the protocol was revised several times after I saw the release of the driver. We could be missing some functionality (unless someone has updated it). > The code must be tested, and merged with your changes, so don't expect > things too soon. I expect system lockups will be gone then, because I sta= rted > to implement the interoperability between the device driver and the file > system. I have definitely already noticed less lockups with Ben's changes, so we are headed in the right direction. > You are unemployed Ben? I was lucky and found a new job. But since my new= job > begins at 15 March or 1 April, I have lot of time for njbfs now. That sux Ben, but you are in Cali right? I think there are more possible jobs out there as compared to the East Coast (nyc area, where I am). I'll be graduating in a couple of months, so I need to look myself. The market seems very tight right now, but it does look like the situation will get better (we hope). This being my last semester, I thought it would go easy, but Murphy's Law prevails always :). I'm going to try to do some work on njbfs this weekend. It seems like the only free time I have is the weekend right now. I'm going to try to organize myself in a better way. If you don't want to checkin the changes to your branch, can you send me a copy? I'll try to integrate an external configuration file setup with the rest of the setup (Jorg sent me a link to a good C API for this, i'll send a link out when I find the right email) . Later, - Danish |
|
From: <joe...@gm...> - 2002-02-23 15:02:33
|
Ben Osheroff wrote:
> It uses an internal njbfs_fattr-based cache which is pretty nice; files in
> different directories share the same core structure.
Cool.
> I've also modified get_attr / njbfs_create to handle file creation more
> gracefully. Now when you upload, it will create the appropriate files in
> all the directories.
Hey a bug fix!
> Do you want to see the code before I check it in? Or should I just finish
> up and check in?
I would suggest just let things roll. Check in the files if they pass your
tests.
Then I can update my local sources and get ready to merge your changes with
my code.
I'm on the way with reorganizing the code for 0.3.
Here is a short summary of changes I am working on since three days,
hopefully you don't totally disagree ;-)
- better source organization
njb.c - base code (status: completed, compileable)
njb_usb.c - usb code (status: 0%, code grabbed from 0.2, not compileable)
njb_tracks.c - track management (usb independent, status: complete)
- track directory entry format string (status: 0%)
- improved and much easier track attribute management (with struct njb_track)
- njb operation table, interface to usb operations
- no more external automount or manual mount required, instead kernel
performs automatic mount and unmount of njbfs
- multiple device support (up to 9 devices), can't be tested (I have only one
njb)
- module parameters: njbfs mount point, track directory entry format string
- throwing out weird code fragments originating from ftpfs
- better integration of nomad device driver, esp. ioctl
- fixing up the mess of cleanup code, memory leaks, missing assertions etc.
I appreciate comments.
The code must be tested, and merged with your changes, so don't expect
things too soon. I expect system lockups will be gone then, because I started
to implement the interoperability between the device driver and the file
system.
You are unemployed Ben? I was lucky and found a new job. But since my new job
begins at 15 March or 1 April, I have lot of time for njbfs now.
Jörg
--
Jörg Prante <jo...@in...>
http://www.infolinux.de +49-228-223151 Mobile +49-175-4661918
GPG fingerprint: 8FB7 C73A BAD4 A7E2 431B 24A2 F47D 5AE2 EE86 4335
GPG Public Key available by request
|
|
From: Ben O. <be...@gi...> - 2002-02-23 13:45:43
|
hi guys, Over the past week or so I've been working on getting the single, monolithic "/tracks" directory structure broken out into classified directories. I'm pretty much done with my work, about ready to check in. It goes like this: /tracks - same as before /genres -> /genres/GENRENAME/[tracks] /artists -> /artists/ARTISTNAME/ALBUMNAME/[tracks] -> /artists/ARTISTNAME/__all__/[tracks] /albums -> /albums/ALBUMNAME/[tracks] It uses an internal njbfs_fattr-based cache which is pretty nice; files in different directories share the same core structure. I've also modified get_attr / njbfs_create to handle file creation more gracefully. Now when you upload, it will create the appropriate files in all the directories. Do you want to see the code before I check it in? Or should I just finish up and check in? -ben (ah, what unemployment will do for your GPL projects) |
|
From: <joe...@gm...> - 2002-02-19 17:25:49
|
Velocet wrote: > root@bathtub:2996 /0 /usr/home/math/udl/njbfs>cat RELEASE.NOTES > This is release 0.3 of njbfs for Linux kernel 2.4.x > > :) Ok I mixed up some files here - sorry for the inconsistence. It should be 0.2.1 > oh one thing is when compiling I got an error - linux/kernel.h is > deprecated, and slab.h should be used (in nomad.c) - I changed the include > file to that instead, should I not do that? (having the right malloc seems > important, no? :) Absolutely. Will be fixed. > when doing this, on the console I get njb_usb.c: TODO: usb delete > > does that mean a feature is unimplimented or just a command to be passed > to the nomad? That means it is unimplemented. > oops was copying a very large file (dont know why i picked that) and > it seems to be taking an extremely long time (over 6-7 minutes for > a 69 meg file) - now the console says "usb_control/bulk_msg: timeout" - > is that NJBFS or the USB modules sayign that? njbfs will be tuned to minimize the USB timeouts. What you see are still the results of a first working nibfs with USB write. > the copy finally completed... but now I dont see the file uploaded in the > tracks dir ... Right. The directory is not updated after a write. This will be fixed. > ... figuring its some caching error, and since all the dirs are equivalent, > I went into albums, and its listed there :) Oh, that is what Danish introduced. > going back to tracks and ls Ba* still not there - is there a way I can > force sync the tracks dir? > > umounting and remounting the tracks dir works of course. That is what I would suggest to do to sync. > However, all this is moot because now I can get files onto it, which is > all I wanted! :) thanks so much! > Great. I really love this module, thanks for the hard work! :) It was for fun! > Is there some way you guys could allow a timeout for njbfs for the nomad so > that it doenst power itself off? Yes. There will be new failsafe features. I think an automatic command termination before the device is unmounted is simply missing. It's not there. > It powered off just at the start of > a command and the command just returned nothing, I powered it back on > and tried ls again and the kernel crashed. There is no check during a command execution if the NJB is still there, only at the beginning of a command. No surprise at all that the kernel crashes. Could you please give some info about how the kernel crashed? Oops, freeze, whatever? Here I got hard locks and the machine has to be rebooted by power off button. > Minor feature request for later - I run this all off my laptop which I can > reboot as much as I want (unlike my desktop which is a more costly reboot) > and with ext3, its fast ;) Same configuration here. Don't hold back requests. We need feature requests to make njbfs better. Thank you for your feedback and keep up Jörg |
|
From: Danish Q. <dx...@nj...> - 2002-02-19 17:09:50
|
> > > Daniel Demus reported: > > > >I was uploading files the Nomad to my harddisk. The > > > >Nomad was on batteries, so it shut down after a time. > > > >This caused my computer to spontaneously reboot. > > > > > > If I understand correctly he is still transferring files with njbfs, when the > > > NJB powers off suddenly. Uhhhhh. Weird. I never tried that. Anybody? > > > > I'm going to try to duplicate it with my setup. My thinking is that if I > > remove the batteries, leave it on AC power and then yank the code I should > > be able to replicate what happens on a power down. Although I think the > > NJB sends a few signals up the pipe right before it powers down? This is > > going to be hard to trace though. > > > > > > I don't think yanking the cable will have the same effect, as, as you > point out, the njb sends something down the line when it shuts down. It > could have been automount and usbmgr having a merry time. > > To give some extra info: > My machine: Dell Latitude CPt, RH 7.2, kernel 2.4.7-10, fresh usbmgr. > > This particular incident happened while it was in the docked, so it > could be some peculiar combination of dodgy docking station, crummy > laptop and agressive messages from the njb. Yeah I was thinking the same thing. Spontaneous rebooting however is not a good thing. Did you have anything in the logs at all? It may help to enable a syslog class for *.debug messages (/etc/syslog.conf), since the NJB spits out some of those too. - Danish |
|
From: Danish Q. <dx...@nj...> - 2002-02-19 15:13:11
|
Not with what I've seen so far. (That's the other reason I'm not using the automounter). I think the concept behind the automounter is keep the directory unmounted until you REALLY need it (in which case you should know what you're looking for. - Danish On Tue, 19 Feb 2002, Daniel Demus wrote: > Is there some way to make these pseudodirectories appear in a file > manager? Otherwise you have to use the command-line to copy files, etc. > from the njb. > > Daniel > > > _______________________________________________ > njbfs-devel mailing list > njb...@li... > https://lists.sourceforge.net/lists/listinfo/njbfs-devel > |
|
From: Daniel D. <da...@de...> - 2002-02-19 09:42:43
|
On Mon, 2002-02-18 at 22:23, J=F6rg Prante wrote: > Hi, >=20 > Just tried 0.2.1 to reproduce the power off reboot. > In Makefile, this will not work: >=20 > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/tracks > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/playlists > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/albums > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/artists >=20 > I wonder what this should do? I only use /mnt/njbfs. 'tracks' is only a=20 > pseudo directory name to 'cd' in. It does not need to exist. The other=20 > entries will confuse users since they are unused yet. >=20 Is there some way to make these pseudodirectories appear in a file manager? Otherwise you have to use the command-line to copy files, etc. from the njb. Daniel |
|
From: Daniel D. <da...@de...> - 2002-02-19 08:54:18
|
On Tue, 2002-02-19 at 03:04, Danish Qadri wrote: >=20 > On Mon, 18 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: >=20 [snip some stuff] >=20 > > Daniel Demus reported: > > >I was uploading files the Nomad to my harddisk. The > > >Nomad was on batteries, so it shut down after a time. > > >This caused my computer to spontaneously reboot. > > > > If I understand correctly he is still transferring files with njbfs, wh= en the > > NJB powers off suddenly. Uhhhhh. Weird. I never tried that. Anybody? >=20 > I'm going to try to duplicate it with my setup. My thinking is that if I > remove the batteries, leave it on AC power and then yank the code I shoul= d > be able to replicate what happens on a power down. Although I think the > NJB sends a few signals up the pipe right before it powers down? This is > going to be hard to trace though. >=20 >=20 I don't think yanking the cable will have the same effect, as, as you point out, the njb sends something down the line when it shuts down. It could have been automount and usbmgr having a merry time. To give some extra info: My machine: Dell Latitude CPt, RH 7.2, kernel 2.4.7-10, fresh usbmgr. This particular incident happened while it was in the docked, so it could be some peculiar combination of dodgy docking station, crummy laptop and agressive messages from the njb. I didn't want to experiment further as I was at work at the time, so I couldn't afford rebooting every 5 minutes. Daniel |
|
From: Danish Q. <dx...@nj...> - 2002-02-19 02:04:51
|
On Mon, 18 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Hi, > > Just tried 0.2.1 but it doesn't work when I try to cd into /mnt/njbfs/tra= cks > and do 'ls' to see the tracks. Nothing appears. In the log I see: > > [...] > Feb 18 23:01:24 jungle kernel: njb_usb.c: capture: device already capture= d > Feb 18 23:01:24 jungle kernel: proc.c: loaddir: unable to get dirlist nod= e > from track > Feb 18 23:01:24 jungle kernel: cache.c: cache_add: couldn't load director= y > Feb 18 23:01:24 jungle kernel: dir.c: njbfs_cache_get failed > Feb 18 23:01:24 jungle kernel: dir.c: reading /, f_pos=3D2 > Feb 18 23:01:24 jungle kernel: cache.c: cache_add: loading directory '/'.= =2E.. > Feb 18 23:01:24 jungle kernel: njb_usb.c: capture: device already capture= d > Feb 18 23:01:24 jungle kernel: proc.c: loaddir: unable to get dirlist nod= e > from track > Feb 18 23:01:24 jungle kernel: cache.c: cache_add: couldn't load director= y > Feb 18 23:01:24 jungle kernel: dir.c: njbfs_cache_get failed > > NJB device locks up until cable is pulled. > > I remember I got that situation in the past when the 'tracks' name doesn'= t > match. Don't know what is going on, but I try to fix it. Might be CVS > changes, might be local problems here, I use kernel 2.4.18-rc1 and devfs. It could be a transient issue, since I do believe that Ben and I are both using 0.2.1+ versions. I'm really hoping that it's not your kernel patches :). Did you try the unmount/unload all usb drivers + njbfs / reload thing? > I need to update the code badly, and will try to update to the njbfs code > part from the new Audiotracks framework which is quite usable. I'm not sure if an update is wise... perhaps creating a new project within the repository would be a better idea? > > >And then there's the issue of who's got the time to implement the > >breakdown of directories. > > Since I'm ready with kernel stuff and writing thesis papers I will turn t= o > the njbfs project again. Speaking of time, I should apologize for not spending enough on the project. I just have to get these two weeks of exams, and I should be good. If I had better time management skills of course, that would help. Or perhaps waking up earlier :) > >Woo hoo, we've got a user! =3D) > > There are more than 100 download counts for 0.2 Those could be us artificially inflating the count :). Actually, I've seen a lot of different users (I think). > Daniel Demus reported: > >I was uploading files the Nomad to my harddisk. The > >Nomad was on batteries, so it shut down after a time. > >This caused my computer to spontaneously reboot. > > If I understand correctly he is still transferring files with njbfs, when= the > NJB powers off suddenly. Uhhhhh. Weird. I never tried that. Anybody? I'm going to try to duplicate it with my setup. My thinking is that if I remove the batteries, leave it on AC power and then yank the code I should be able to replicate what happens on a power down. Although I think the NJB sends a few signals up the pipe right before it powers down? This is going to be hard to trace though. - Danish |
|
From: <joe...@gm...> - 2002-02-18 22:52:03
|
Hi, Just tried 0.2.1 but it doesn't work when I try to cd into /mnt/njbfs/tracks and do 'ls' to see the tracks. Nothing appears. In the log I see: [...] Feb 18 23:01:24 jungle kernel: njb_usb.c: capture: device already captured Feb 18 23:01:24 jungle kernel: proc.c: loaddir: unable to get dirlist node from track Feb 18 23:01:24 jungle kernel: cache.c: cache_add: couldn't load directory Feb 18 23:01:24 jungle kernel: dir.c: njbfs_cache_get failed Feb 18 23:01:24 jungle kernel: dir.c: reading /, f_pos=2 Feb 18 23:01:24 jungle kernel: cache.c: cache_add: loading directory '/'.... Feb 18 23:01:24 jungle kernel: njb_usb.c: capture: device already captured Feb 18 23:01:24 jungle kernel: proc.c: loaddir: unable to get dirlist node from track Feb 18 23:01:24 jungle kernel: cache.c: cache_add: couldn't load directory Feb 18 23:01:24 jungle kernel: dir.c: njbfs_cache_get failed NJB device locks up until cable is pulled. I remember I got that situation in the past when the 'tracks' name doesn't match. Don't know what is going on, but I try to fix it. Might be CVS changes, might be local problems here, I use kernel 2.4.18-rc1 and devfs. I need to update the code badly, and will try to update to the njbfs code part from the new Audiotracks framework which is quite usable. >And then there's the issue of who's got the time to implement the >breakdown of directories. Since I'm ready with kernel stuff and writing thesis papers I will turn to the njbfs project again. >Woo hoo, we've got a user! =) There are more than 100 download counts for 0.2 Daniel Demus reported: >I was uploading files the Nomad to my harddisk. The >Nomad was on batteries, so it shut down after a time. >This caused my computer to spontaneously reboot. If I understand correctly he is still transferring files with njbfs, when the NJB powers off suddenly. Uhhhhh. Weird. I never tried that. Anybody? Jörg |
|
From: Ben O. <be...@gi...> - 2002-02-18 21:54:07
|
On Mon, 18 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Danish Qadri wrote: > > Have we discussed how we want to setup the other mounted directories? I > > can see playlists and albums both being interesting to say the least. I > > guess we could in a way use symlinks to the master "tracks" directory t= o > > maintain consistency, or just reduplicate the file entry in each direct= ory > > if need be. The other issue is how we name our files I guess. > > We don't need to create symlinks, since the files are always on the NJB > stored remotely. A dentry copy doesn't hurt, even if the remote access tr= ack > ID is the same. Symlinks can be useful if njbfs needs to store etxra file > attributes in the file name as clear text automatically, which may look u= gly, > but the user should still see the original filename. I agree, as long as we keep the inode the same between dentry's (basically we'll have a "hard link", no?) I think file naming should take on different forms under the different directories: tracks should have "Artist - Title" by default, albums should have "title" by default should artists be a list of all the artists files in one dir, or subdivided by album directories? I think subdivided by album directories, myself. And then there's the issue of who's got the time to implement the breakdown of directories. Woo hoo, we've got a user! =3D) -ben |
|
From: Danish Q. <dx...@nj...> - 2002-02-18 21:28:55
|
That was to create the mount points for people not using the automounter. I have my njbfs automounted at /mnt/njbfs_auto. Eventually I was going to have that come out of the configure script after some tests. I never get around to it, I guess. Sorry :) - Danish On Mon, 18 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Hi, >=20 > Just tried 0.2.1 to reproduce the power off reboot. > In Makefile, this will not work: >=20 > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/tracks > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/playlists > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/albums > install -d -m755 --owner=3D0 --group=3D0 /mnt/njbfs/artists >=20 > I wonder what this should do? I only use /mnt/njbfs. 'tracks' is only a= =20 > pseudo directory name to 'cd' in. It does not need to exist. The other=20 > entries will confuse users since they are unused yet. >=20 > J=F6rg >=20 > _______________________________________________ > njbfs-devel mailing list > njb...@li... > https://lists.sourceforge.net/lists/listinfo/njbfs-devel >=20 |
|
From: <joe...@gm...> - 2002-02-18 21:25:31
|
Hi,
Just tried 0.2.1 to reproduce the power off reboot.
In Makefile, this will not work:
install -d -m755 --owner=0 --group=0 /mnt/njbfs/tracks
install -d -m755 --owner=0 --group=0 /mnt/njbfs/playlists
install -d -m755 --owner=0 --group=0 /mnt/njbfs/albums
install -d -m755 --owner=0 --group=0 /mnt/njbfs/artists
I wonder what this should do? I only use /mnt/njbfs. 'tracks' is only a
pseudo directory name to 'cd' in. It does not need to exist. The other
entries will confuse users since they are unused yet.
Jörg
|
|
From: <joe...@gm...> - 2002-02-18 21:00:48
|
Danish Qadri wrote: > Have we discussed how we want to setup the other mounted directories? I > can see playlists and albums both being interesting to say the least. I > guess we could in a way use symlinks to the master "tracks" directory to > maintain consistency, or just reduplicate the file entry in each directory > if need be. The other issue is how we name our files I guess. We don't need to create symlinks, since the files are always on the NJB stored remotely. A dentry copy doesn't hurt, even if the remote access track ID is the same. Symlinks can be useful if njbfs needs to store etxra file attributes in the file name as clear text automatically, which may look ugly, but the user should still see the original filename. Playlists need additional NJB interaction, while artist/album lists can be derived from the full track listing. Yes, I would like to see those features in 0.3 > In the albums directory, would you want to see the album name listed again > for each track? Although I would think that you would want to see the > Album name in the "tracks" directory. > > Or perhaps a configurable setup? Jorg sent me a link to a good C package > to handle configuration files, but I think I lost it. Jorg, do you > remember which link I'm talking about? The configuration should be discussed. I saw in EasyTAG a solution which contains format strings, like "%a - %t.%c" where a - artist, t - title, c - codec. Those format strings could also be given as njbfs mount parameters, with a rather obvious default. That doesn't need the extra setup of a config file. Anayway, here is the link I sent you: http://www.azzit.de/dotconf/ "dot.conf is an easy to use and powerful configuration file parser library. The configuration files created for dot.conf look very similar to those used by the Apache Webserver. " Jörg |
|
From: Danish Q. <dx...@nj...> - 2002-02-18 13:06:05
|
Have we discussed how we want to setup the other mounted directories? I can see playlists and albums both being interesting to say the least. I guess we could in a way use symlinks to the master "tracks" directory to maintain consistency, or just reduplicate the file entry in each directory if need be. The other issue is how we name our files I guess. In the albums directory, would you want to see the album name listed again for each track? Although I would think that you would want to see the Album name in the "tracks" directory. Or perhaps a configurable setup? Jorg sent me a link to a good C package to handle configuration files, but I think I lost it. Jorg, do you remember which link I'm talking about? - Danish |
|
From: Danish Q. <dx...@nj...> - 2002-02-17 20:55:03
|
It's all good, I'll update the list on the njbfs.sf.net web page. - Danish On Sun, 17 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Am Sonntag, 17. Februar 2002 18:53 schrieb Danish Qadri: > > BTW, this would be from the main branch right? > > > > If no one has done it, I'll do it tonight, just let me know. I thought = we > > had already done it, and sent a few messages out to some bug reporters = to > > try out the new version. > > 0.2.1 is out - it's from the main branch. See my last mail. Sorry I didn'= t > set up neither a proper ANNOUNCE mail nor a mail notification to the bug > reporters. > > J=F6rg > > _______________________________________________ > njbfs-devel mailing list > njb...@li... > https://lists.sourceforge.net/lists/listinfo/njbfs-devel > |
|
From: <joe...@gm...> - 2002-02-17 20:48:24
|
Am Sonntag, 17. Februar 2002 18:53 schrieb Danish Qadri: > BTW, this would be from the main branch right? > > If no one has done it, I'll do it tonight, just let me know. I thought we > had already done it, and sent a few messages out to some bug reporters to > try out the new version. 0.2.1 is out - it's from the main branch. See my last mail. Sorry I didn't set up neither a proper ANNOUNCE mail nor a mail notification to the bug reporters. Jörg |
|
From: Danish Q. <dx...@nj...> - 2002-02-17 17:55:51
|
BTW, this would be from the main branch right? If no one has done it, I'll do it tonight, just let me know. I thought we had already done it, and sent a few messages out to some bug reporters to try out the new version. - Danish |
|
From: Danish Q. <dx...@nj...> - 2002-02-17 17:47:20
|
On Thu, 14 Feb 2002, Ben Osheroff wrote: > On Fri, 15 Feb 2002, Danish Qadri wrote: > > > > > > > > -Writes, esp with consideration to creating files, auto-recognizing id3 > > > tags, and creating a more transparent writing system. Jorge, you had > > > mentioned (in some documentation somewhere) that you were working on a > > > system to cache the file in the kernel when it's written and commit it > > > when its done... any progress on that? > > > > I was definitely thinking that the above is a good idea. It will > > definitely increase our memory usage (if we want to buffer the entire > > file, then significantly), but otherwise would be a useful feature. > > If the nomad is as good with writes as it is with reads, we may have to > buffer the entire file for even a small change =) > > Another, simpler option might be to not allow file changes with the > exception of changes to the mp3 tag (which we would translate into nomad > tag changes). We could allow create & delete but not modify. Although > I'm not sure that's possible with VFS. I was thinking of handicapping njbfs by removing the actual modify command. Alternatively (and this is not pretty), we could rewrite modify to do the following. I assume we will know what is being changed and where. We create a new file with the same name (different nomad track tag #), write everything. Then delete the old file, and (somehow) have the nomad change the new tag # to the original one. > > >From what you mentioned before, the NJB doesn't like seeking, so I'm not > > sure what possibilities we have for a read ahead. One of our biggest > > problems is how slow the USB interface. BTW, a separate question... if you > > had an external USB hard drive, is the transfer rate fast enough to > > support Winamp/XMMS directly? I will investigate this issue though, and > > see if an intelligent read ahead is possible. > > Yeah, I've been thinking about this. The only solution I've come up with > is: > > -VFS requests a read > -We do the read as requested, and set a timer. > -The timer calls a read ahead function that gets some blocks and stores > them in a buffer. > -The next time VFS requests a read, it's already in our buffer, so we can > just return that without requesting another read from the jukebox. > > the problem with this is, I don't know if you can get to user context > (where we can do a usb read without blocking the kernel) with a timer. > There also looks like there's some hope in usb "urbs" (looks like > asynchronous usb i/o) but I don't fully understand how they work yet. I'm not sure if urbs are supported in kernel space (it would help immensely). I'll look around, [looks around in /usr/src/linux/include/usb.h]... Wow. I do believe we have kernel level support for urbs. And it's pretty cool. One thing that caught my eye very quickly is that you can specify how much of a transfer rate you want to allocate to each request (I'm not sure how well that works though). So in theory we could be transferring files, while playing some through the NJB itself (probably not stream a file and transfer at the same time). Strange thing is that there is a lot of *Microsoft* documentation on using URBs. It may hold some useful knowledge (maybe :). I'll try searching the web and the src for some more ideas. URBs are used for control as well as for data transfers, and I'm surprised we don't have any of that in the nomad.c usb code. (Well I didn't see any occurrences of urb in the libnjb code either). Considering that we can also think of the njb as a usb HD, I think we might find some good ideas in the usb mass storage driver. > Where are you from, anyway? Heheheh.. I'm a senior college student at the New Jersey Institute of Technology, majoring in Computer Engineering and Applied Mathematics. Lots of fun, eh? :) BTW guys, you may want to subscribe to the njbfs-bugs list, it seems we are getting more users. The most common complaint is the missing sscanf for kernels < 2.4.10. I can't figure out how to reach Matthias (original bug complaint), he didn't leave an email. IIRC, I think he's over at nomadness.net - Danish |
|
From: Ben O. <be...@gi...> - 2002-02-15 20:09:55
|
as you may have seen, I've started the "ben" branch in the cvs tree. This will contain my playing-around stuff. I fucked up the first couple of times (nomad_usb.h, njbfs.h) and had to rollback to version 1.4. Also, I checked in a small change to the main branch that was preventing it from compiling under 2.4.9. -ben |
|
From: <joe...@gm...> - 2002-02-15 15:21:43
|
Danish Qadri wrote: > How about we change the block size in CVS first? I think any users we have > would find it more useful. Okay, 0.2.1 is out, then we go for 0.2.2 Let me try out 0.2.1 first, I will add the buffer size change then. > Also, has anyone else noticed the hard drive sounds when you transfer a > file through njbfs? I'm going to sit down and compare it to Playcenter on > Windows, but I'm almost sure that it's not doing something right... It > could be my unit though. I noticed some pausing when uploading with 0.2. The NJB is idle when njbfs is sending too slow, the drive will slow down and start again when the transfer resumes. Since 0.2 was the first version that could upload to the device, I was happy about the basics done and didn't pay too much attention to the tuning. The NJB won't get broken, since the USB acess is separate from the NJB drive control. PlayCenter uses very few USB control messages to transfer a file and lot of USB bulk data. I noticed it takes approx. 20-30 secs for a 3.5 MB file. With 4K buffers, njbfs is sending less USB control messages and longer USB data bulks than with 1k buffers. And, it takes 30-40 secs for the same file which is acceptable. With 1k buffers, I remember it took up to 3-4 minutes. But these values should be benchmarked. Offtopic: I did some Linux kernel building lately, if you dare to test a bleeding edge 2.4.18-rc1-jp5 kernel, take a look at http://infolinux.de Jörg |
|
From: Danish Q. <dx...@nj...> - 2002-02-15 14:06:50
|
How about we change the block size in CVS first? I think any users we have would find it more useful. Also, has anyone else noticed the hard drive sounds when you transfer a file through njbfs? I'm going to sit down and compare it to Playcenter on Windows, but I'm almost sure that it's not doing something right... It could be my unit though. - Danish On Fri, 15 Feb 2002, [iso-8859-15] J=F6rg Prante wrote: > Ben Osheroff wrote: > > Should we publish a 0.2.1 update with the source tree as it stands? Th= e > > track listings and the 2.4.9 compilation fixes seem pretty important to > > me... >=20 > OK. I will publish a 0.2.1 release from the CVS repository. >=20 > J=F6rg >=20 > _______________________________________________ > njbfs-devel mailing list > njb...@li... > https://lists.sourceforge.net/lists/listinfo/njbfs-devel >=20 |
|
From: <joe...@gm...> - 2002-02-15 09:47:04
|
Ben Osheroff wrote: > Is there a reason we're calling a njb_usb_handshake on every call to > njb_usb_open? The handshake functions seems to add about 1-3 seconds onto > every call. I tried to follow the suggestions in the NJB protocol document at libnjb.sf.net Jörg |
|
From: <joe...@gm...> - 2002-02-15 09:45:18
|
Ben Osheroff wrote: > Should we publish a 0.2.1 update with the source tree as it stands? The > track listings and the 2.4.9 compilation fixes seem pretty important to > me... OK. I will publish a 0.2.1 release from the CVS repository. Jörg |
9 messages has been excluded from this view by a project administrator.
