jfs4bsd-devel Mailing List for JFS for DragonFly BSD
Status: Alpha
Brought to you by:
h_pandya
Menu
▾
▴
jfs4bsd-devel — Development discussions regarding the port are made on this list.
You can subscribe to this list here.
| 2002 |
Jan
(11) |
Feb
|
Mar
(5) |
Apr
(19) |
May
(23) |
Jun
(28) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sean C. <sc...@us...> - 2003-03-03 18:53:18
|
Hello, all. First off, I'm not quite even a new bsd user yet, but I'm planning on installing OpenBSD, once i can figure out how i want to partion and format the new drive. When I was looking around the xfs pages at oss.sgi.com, I found a link to the following patch, within the XFS faq[1] ftp://ftp.uni-duisburg.de/linux/filesys/JFS_with_XFS.patch If I understood the FAQ correctly, and the name of the patch, this is maybe for mounting xfs volumes as jfs? Maybe this is just wishful thinking. Assuming that it may be 'for real' though, I was wondering whether that patch might be applied to the jfs4bsd sources, and then whether it might gives us a means to mount XFS volumes from within BSD. But, I'm still stuck in a loop about which linux kernel to use, and whether or not to even try xfs on my own box, so i thought i'd bring it up now, to see what might come about in the discussion. As for getting jfs4bsd to work on OpenBSD .. that would be another subject, heh. I'm open to suggestions though. thanks -- sean sc...@us... ------------------------------------------------------------ Footnotes: [1] http://oss.sgi.com/projects/xfs/faq.html#jfsplusxfs |
|
From: Sergey L. <de...@as...> - 2002-07-17 14:25:23
|
On Mon, Jul 15, 2002 at 04:57:08PM -0400, Hiten Pandya wrote: > Hello everyone. > > I have finally come to think, that we are just wasting ample time trying > to port Metapages; also, Sergey has disappeared, so I was wondering, > that we should just remove Metapages completely. Did you mean, remove the layer completely ? I beleive vfs_bio.c does all the caching needed, so I have planned to make a stubs in jfs_bufmgr.[ch] so that to preserve the metapage interface (to ease the things), but make the use of struct buf inside them. the only difficulty i see in using bio interface directly is that struct jbuf (struct metapage) holds some additional info (log stuff etc), instead just on-disk data, and the code accesses it. that is why I have considered keeping struct jbuf and metapage interface. but probably that info may be moved to struct inode, freeing us from buffering stuff at all. dropping metapage interface sounds as a good idea, on the other side, keeping it looks as a good choice as well (by the means of keeping just the interface, redirecting all work to the vfs bio code). I don't know, at this point, what is the best way :-) -- Sergey Lyubka Asita Technologies Int, Galway, Ireland |
|
From: Hiten P. <hit...@ya...> - 2002-07-15 20:57:21
|
Hello everyone. I have finally come to think, that we are just wasting ample time trying to port Metapages; also, Sergey has disappeared, so I was wondering, that we should just remove Metapages completely. I think metapages is just a buffer cache management layer pushed down into the JFS; like buffer/cache managers in XFS and ReiserFS. I am planning to use struct buf wherever possible, unless someone has a better idea. Also, providing a buffer cache interface, like mp_init() etc does not make sense, because I dont think anyone will be using FreeBSD JFS for porting it to other BSDs, and even then, it should be easy. This is the only blockade I am facing at the moment. Apart from that, there are the diRead*() related functions which I need to port, once they have been done, I can cleanup the JFS Mount patch I have to do read mounts; most of the other stuff is done... If anyone has better ideas on how to proceed; please do not hesitate to put them forward. Thank You. Yours Truly. -- Hiten Pandya http://www.unixdaemons.com/~hiten hi...@un..., hi...@uk..., hi...@xM... |
|
From: Greg 'g. L. <gr...@Fr...> - 2002-07-07 00:18:20
|
On Friday, 21 June 2002 at 19:18:06 -0700, Hiten Pandya wrote: > --- Greg 'groggy' Lehey <gr...@Fr...> wrote: >> On Friday, 21 June 2002 at 11:27:41 -0700, h_p...@so... wrote: >>> Log Message: >>> Update the license to GPL. It is better to stay on one license >>> throughout the codebase, rather than mix n' matching BSD and GPL >>> licenses, thus providing sense of uniformity. >> >> Thanks. You appear to have missed the point, though: the issue here >> is not uniformity of the code, but that this is IBM code which was >> released under the GPL. > > I understand what you mean. struct jfsmount was my creation so I have my > copyright on it, although, I have a nice suggestion, each newly created > file should have the copyright of the owner and IBM on it, due to the use > of its data structures, yada yada yada.. :) > > Example: > > /*- > * Copyright (c) 2002 <authorname> [<authoremail>] > * Copyright (c) Internation Business Machines (IBM) Corporation 2000 > * > * <begin GPL license here> > * <if code from OS/2 codebase, then add the SCCS id carried by it> > * $Id$ > */ > > Let me know if this is right Greg. This will make sure that no IBM law or > copyright has been violated by the use of its creations, right? Yes, I don't see any problem with that. Greg -- See complete headers for address and phone numbers |
|
From: Hiten P. <hit...@ya...> - 2002-07-01 22:01:25
|
--- h_p...@us... wrote: > Log Message: > Add commitlog Woohoo! Eureka! I found the problem. Simple and short; SourceForge.net needs to improve their syncmail scripts. When syncmail sends the mail, it prepares user@domain for the From: bit; when the mail is sent to a SourceForge Mailing list, it fails because fo...@so... is not valid, but if we have the users. bit in the From: field, than the SourceForge finger-back test succeeds and the mail goes to its (SourceForge) destination! :-)) --> (CVSROOT/syncmail diff) + author = '%s@users.%s' % (user, domain) - author = '%s@%s' % (user, domain) <-- Apart from that, I apologise for using this list. I will fix this in the JFS4BSD Project as well. Thanks -- Hiten __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: <h_p...@us...> - 2002-07-01 21:49:57
|
Update of /cvsroot/ng-httpd/CVSROOT
In directory usw-pr-cvs1:/tmp/cvs-serv22920
Modified Files:
loginfo
Log Message:
Remove jfs4bsd-devel@ from the commit list. it was only for test.
Index: loginfo
===================================================================
RCS file: /cvsroot/ng-httpd/CVSROOT/loginfo,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- loginfo 1 Jul 2002 21:39:34 -0000 1.5
+++ loginfo 1 Jul 2002 21:49:52 -0000 1.6
@@ -25,5 +25,5 @@
#DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog
# or
DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog
-#DEFAULT $CVSROOT/CVSROOT/syncmail -u %{sVv} hit...@ya... km...@ne...
-CVSROOT $CVSROOT/CVSROOT/syncmail -u %{sVv} hit...@ya... km...@ne... jfs...@li...
+DEFAULT $CVSROOT/CVSROOT/syncmail -u %{sVv} hit...@ya... km...@ne...
+CVSROOT $CVSROOT/CVSROOT/syncmail -u %{sVv} hit...@ya... km...@ne...
|
|
From: <h_p...@us...> - 2002-07-01 21:42:45
|
Update of /cvsroot/ng-httpd/CVSROOT In directory usw-pr-cvs1:/tmp/cvs-serv20775 Modified Files: checkoutlist Log Message: Add commitlog Index: checkoutlist =================================================================== RCS file: /cvsroot/ng-httpd/CVSROOT/checkoutlist,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- checkoutlist 1 Jul 2002 21:41:53 -0000 1.2 +++ checkoutlist 1 Jul 2002 21:42:41 -0000 1.3 @@ -12,3 +12,4 @@ # # comment lines begin with '#' syncmail +commitlog |
|
From: Alexander K. <ak...@gt...> - 2002-06-28 16:06:55
|
DIOCGMEDIASIZE ioctl works just find with all types of devices on GEOM kernel. I fixed the non-GEOM case and sent the patch to phk. We'll see if he thinks that patch is good enough for commit. -- Alexander Kabaev |
|
From: Sergey L. <de...@as...> - 2002-06-28 08:33:02
|
time_t changed to struct timestruc_t in jfs_inode.h.
would the following code in imap.c cause an endianness problem:
Index: jfs_imap.c
===================================================================
RCS file: /cvsroot/jfs4bsd/j4b/src/sys/gnu/jfs/jfs_imap.c,v
retrieving revision 1.14
diff -r1.14 jfs_imap.c
3081,3083c3081,3083
< ip->i_atime = le32_to_cpu(dip->di_atime.tv_sec);
< ip->i_mtime = le32_to_cpu(dip->di_mtime.tv_sec);
< ip->i_ctime = le32_to_cpu(dip->di_ctime.tv_sec);
---
> (void) memcpy(&ip->i_atime, &dip->di_atime, sizeof(struct timestruc_t));
> (void) memcpy(&ip->i_mtime, &dip->di_mtime, sizeof(struct timestruc_t));
> (void) memcpy(&ip->i_ctime, &dip->di_ctime, sizeof(struct timestruc_t));
3145c3145
< dip->di_atime.tv_sec = cpu_to_le32(ip->i_atime);
---
> dip->di_atime.tv_sec = cpu_to_le32(ip->i_atime.tv_sec);
3147c3147
< dip->di_ctime.tv_sec = cpu_to_le32(ip->i_ctime);
---
> dip->di_ctime.tv_sec = cpu_to_le32(ip->i_ctime.tv_sec);
3149c3149
< dip->di_mtime.tv_sec = cpu_to_le32(ip->i_mtime);
---
> dip->di_mtime.tv_sec = cpu_to_le32(ip->i_mtime.tv_sec);
Also, I have found the type name `struct timestruc_t' somewhat
messy. `_t' suffix is usually added to type names, not to
struct tags. Should we change it to something like
typedef { ... } timestruc_t;
or,
struct timestruct { ... };
Sergey.
On Fri, Jun 28, 2002 at 09:44:08AM +0930, Greg 'groggy' Lehey wrote:
> On Thursday, 27 June 2002 at 7:13:30 -0700, dr...@so... wrote:
> > Update of /cvsroot/jfs4bsd/j4b/src/sys/gnu/jfs
> > In directory usw-pr-cvs1:/tmp/cvs-serv18255
> >
> > Modified Files:
> > jfs.h
> > Log Message:
> > CURRENT_TIME defined to0. probably it should be defined to the
> > number of seconds since epoch
>
> I'd strongly recommend not using time_t here. Something with higher
> resolution is almost obligatory. timestruc_t might be a possibility,
> since you're going to need it anyway for the on-disk formats.
>
> Greg
> --
> Finger gr...@le... for PGP public key
> See complete headers for address and phone numbers
--
Sergey Lyubka
Asita Technologies Int, Galway, Ireland
|
|
From: Alexander K. <ak...@gt...> - 2002-06-27 18:28:36
|
Ok, I was able to reproduce this. I never tried to use _slices_ on md disks before, but I remember that this code used to work just fine on my IDE disk slices. Now it fails, so I will have to look in more detail when I have time. Old method is not affected in any way. May be you should be using it for now? -- Alexander Kabaev |
|
From: Martin F. <gmh...@br...> - 2002-06-27 15:35:03
|
On 2002.06.27 10:43:59 +0000, Alexander Kabaev wrote:
> Per our discussion on #bsdcode with redpixel (who are you, BTW?),
My real name is Martin Fax=E9r.
> I resurrected my sample program which uses DIOCGMEDIASIZE to get the
> size of disk devices, partitions and slices. Unfortunately, I forgot
> what exactly problems you were having :(
I can't seem to find out the size of a single slice/partition using
DIOCGMEDIASIZE. Here's an example:
lockdown# mdconfig -l
md4 vnode 61440 KBytes
lockdown# fdisk md4
******* Working on device /dev/md4 *******
[... All other partitions are <UNUSED> ...]
The data for partition 4 is:
sysid 172 (0xac),(IBM JFS)
start 63, size 122787 (59 Meg), flag 80 (active)
beg: cyl 1/ head 0/ sector 1;
end: cyl 925/ head 0/ sector 63
lockdown# ./a.out /dev/md4
New method:
Device to test: /dev/md4
Bytes: 62914560
Sectors: 122880
Kilobytes: 61440
Megabytes: 60
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
Old method:
Device to test: /dev/md4
Bytes: 62914560
Sectors: 122880
Kilobytes: 61440
Megabytes: 60
[ I modified your program to let it continue even if the ioctl()
failed. ]
lockdown# ./a.out /dev/md4s4
ioctl(2) failed
Old method:
Device to test: /dev/md4s4
Bytes: 62866944
Sectors: 122787
Kilobytes: 61393
Megabytes: 59
If you've got any ideas of how to solve this, I'd be most grateful to
hear them. Thanks!
Regards,
Martin Fax=E9r
|
|
From: Alexander K. <ak...@gt...> - 2002-06-27 14:44:11
|
Per our discussion on #bsdcode with redpixel (who are you, BTW?), I resurrected my sample program which uses DIOCGMEDIASIZE to get the size of disk devices, partitions and slices. Unfortunately, I forgot what exactly problems you were having :( Every my test case is working just fine. -- Alexander Kabaev |
|
From: Sergey L. <de...@as...> - 2002-06-27 08:45:20
|
On Wed, Jun 26, 2002 at 03:39:18PM -0700, Hiten Pandya wrote: > --- dr...@so... wrote: > called jfs_misc.c because they are used all over the JFS codebase. Other *_subr.c is used as a file with misc functions. probably it is better to follow the tradition ? > > if (S_ISCHR(ip->i_mode) || S_ISBLK(ip->i_mode)) > > - dip->di_rdev = cpu_to_le32(kdev_t_to_nr(ip->i_rdev)); > > + dip->di_rdev = ip->i_rdev; > > Hmm. I am a bit concerned about this bit. This convert would raise a heck > lot of endian issues, and secondly, the kdev_t_to_nr() routine is used to > return the major and minor number of the corresponding device pointed to by > kdev_t in Linux. Our functionally equivalent would be dev2unit() which is > prototyped in /sys/kern/kern_conf.c. > > The correct version should look like: > dip->di_rdev = cpu_to_le32(dev2unit(ip->i_rdev)); yes, you're absolutely right ! I have a lot of work to be done on jfs_imap.c, anyway. I had this issue marked in my notebook, so I planned to fix it. And, sure, that is not the only thing to be fixed there. > One more thing is important. It is very important to post some patches on > the net for review, which make big changes for the only reason that it can > be reviewed; and we should not just try and get things compiling if they dont > appear right in the first place... it would just provide us with wrong > results, hence sucking all our time in debugging with gdb. :-) yes, that's a good point. -- Sergey Lyubka Asita Technologies Int, Galway, Ireland |
|
From: Hiten P. <hit...@ya...> - 2002-06-26 22:39:22
|
--- dr...@so... wrote: > Log Message: > it is compiles now Hi. Some things I had to point out. First of all, I am working on chkSuper(), updateSuper() and readSuper() as well as logMOUNT(). The last three are done, but the other one is a tough cookie. ;) Nevertheless, I am planning to put these four routines in a seperate file called jfs_misc.c because they are used all over the JFS codebase. Other thing is, I have got jfs_mountfs(), and jfs_mount() ported. Once they compile cleanly, I will add them straight to the jfs_vfsops.c file. I have a request. Please dont make any changes to the jfs_nmount.c, and you can leave the jfs_mount and jfs_mountfs for now, as I will be committing them soon; which will give you a more better base. > if (S_ISCHR(ip->i_mode) || S_ISBLK(ip->i_mode)) > - dip->di_rdev = cpu_to_le32(kdev_t_to_nr(ip->i_rdev)); > + dip->di_rdev = ip->i_rdev; Hmm. I am a bit concerned about this bit. This convert would raise a heck lot of endian issues, and secondly, the kdev_t_to_nr() routine is used to return the major and minor number of the corresponding device pointed to by kdev_t in Linux. Our functionally equivalent would be dev2unit() which is prototyped in /sys/kern/kern_conf.c. The correct version should look like: dip->di_rdev = cpu_to_le32(dev2unit(ip->i_rdev)); One more thing is important. It is very important to post some patches on the net for review, which make big changes for the only reason that it can be reviewed; and we should not just try and get things compiling if they dont appear right in the first place... it would just provide us with wrong results, hence sucking all our time in debugging with gdb. :-) I am sure you understand. I apologise if I sounded blunt, but I didnt mean to sound like that. ;) Hope that helps. :-) Regards. -- Hiten Pandya -- <hi...@uk...> __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Martin F. <gmh...@br...> - 2002-06-26 17:49:02
|
On 2002.06.26 16:16:47 +0000, Sergey Lyubka wrote: > I would like to suggest using jfs.h as a centralized place > for temporary #defines and other bogus stuff, so > if something still needs porting, it would be visible immediately. > > say, I have put atomic_* macros there, > jfs.h is not correct place for it, probably jfs_atomic.h is better. > > but if the bogus/temporary things are centralized, it would be > easier to manage them later. > > opinions ? That sounds good to me! |
|
From: Sergey L. <de...@as...> - 2002-06-26 15:15:28
|
I would like to suggest using jfs.h as a centralized place for temporary #defines and other bogus stuff, so if something still needs porting, it would be visible immediately. say, I have put atomic_* macros there, jfs.h is not correct place for it, probably jfs_atomic.h is better. but if the bogus/temporary things are centralized, it would be easier to manage them later. opinions ? Sergey |
|
From: Hiten P. <hit...@ya...> - 2002-06-25 20:28:15
|
--- Sergey Lyubka <de...@as...> wrote: > A question about the subject, struct jfs_sb_info, > declared in jfs_incore.h > > It is obsoleted by the struct jfsmount, isn't it ? Yes. > So, is the entire jfs_incore.h obsoleted ? Well, not really, there is the cflags which we need, but it would be advised for it not to be removed for now; this applies for the other files inode.c file.c and super.c (and namei.c) as well. They contain useful info for us. -- Hiten __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Sergey L. <de...@as...> - 2002-06-25 09:29:02
|
A question about the subject, struct jfs_sb_info, declared in jfs_incore.h It is obsoleted by the struct jfsmount, isn't it ? And what does struct jfs_inode_info in the same file mean ? As far as I can understand, it should represent the in-core inode. But we have struct inode (in-core) and struct dinode (on-disk) already. So, is the entire jfs_incore.h obsoleted ? -sergey |
|
From: Martin F. <gmh...@br...> - 2002-06-24 23:21:39
|
> On Tuesday, 11 June 2002 at 9:25:08 -0700, chris wrote: > > hi, Hi! > > i'm interrested in joining temporary to youre > > developement group. > > I'm very skilled in C and driver developement. That sounds very good! We greatly appreciate any extra help we can get. > > Unfortunatly I have little experience with FreeBsD > > VFS layer (only one minor project). That's OK; most of us are junior kernel hackers but with a great desire to learn more. > > My focus is to make one jfs on CD-Rom with incremental > > packet writing without the overhead of (unfinished and > > space consuming) UFS. Hum, OK... I'm not really sure if what you're saying is that you want to use JFS as a file system or if you're generally designing your own. If you're designing your own I guess JFS won't be of much help to you, although if you've got any questions about VFS we might be able to answer some of them. If you are indeed wanting to use JFS as a file system for doing incremental writes to a CD-R, I think it will need some modification to support that, ie. you'd have to set aside some space for "superblocks" and then modify it to write a new superblock after the last one each time you update it, instead of overwriting the old one, and so on... > > Currently i'm planning some Interfaces and write some > > specification for this purpose. OK. Feel free to send them over and we'll see if it looks like we could join forces. > > The timeline for begin of coding (mostly kernel space) is > > in approximal tree weeks. > > > > If your are interrested, we can join the effords. > > Sincerly > > Chris S. If you want to get in contact with us the best way is probably to send a mail to the jfs4bsd-devel list at SourceForge. =20 See http://sourceforge.net/mail/?group_id=3D42115 for more info on how to subscribe. There's also an IRC channel, if you prefer that. It's called #JFS4BSD and is on the EFNet IRC network. There might not be people there at all times but if you stick around for a while we'll probably drop in sooner or later. Yours sincerely, Martin Fax=E9r |
|
From: Greg 'g. L. <gr...@le...> - 2002-06-24 23:04:22
|
On Tuesday, 11 June 2002 at 9:25:08 -0700, chris wrote: > hi, > i'm interrested in joining temporary to youre > developement group. > I'm very skilled in C and driver developement. > Unfortunatly I have little experience with FreeBsD > VFS layer (only one minor project). > My focus is to make one jfs on CD-Rom with incremental > packet writing without the overhead of (unfinished and > space consuming) UFS. > Currently i'm planning some Interfaces and write some > specification for this purpose. > The timeline for begin of coding (mostly kernel space) is > in approximal tree weeks. > > If your are interrested, we can join the effords. > Sincerly > Chris S. Sorry for the slow reply. I'm not overly active in the development group; I'm forwarding this message to the mailing list. I expect that somebody will get back to you. Greg -- Finger gr...@le... for PGP public key See complete headers for address and phone numbers |
|
From: Martin F. <gmh...@br...> - 2002-06-24 12:28:35
|
On 2002.06.24 05:18:03 +0000, red...@so... wrote:
> Update of /cvsroot/jfs4bsd/j4b/src/sys/gnu/jfs
> In directory usw-pr-cvs1:/tmp/cvs-serv32437
>
> Modified Files:
> jfs_nmount.c
> Log Message:
> o Begin fixing up this file to be in a close-to-compilable state.
> It's still not compilable but at least it's a little bit closer.
> The majority of the changes were:
> - fixing dprintf() arguments
> - a few syntax errors
> - missing prototype for jfs_readSuper()
^^^^^^^^^^^^^^^
I meant jfs_mountfs() of course...
|
|
From: Sergey L. <de...@as...> - 2002-06-24 09:20:08
|
On Mon, Jun 24, 2002 at 01:32:44AM -0700, Hiten Pandya wrote: > --- Sergey Lyubka <de...@as...> wrote: > > Hi Hiten, > > Hi! :) > > > few comments about the patch. > > > > line 187: you're calling chkSuper, > > but superblock has not being read into memory yet, > > and mout structure has not being alloc-ed. > > I apologise, but if you have a look at the code for chkSuper() which is in > the JFS4BSD repository, (sorry, I didn't include it in the patch because it > is not ported yet) then you will notice that it is chkSuper() which does > the reading of the superblock into memory; or am I missing a point? Auch :-) yes, it is OK, chkSuper allocates the memory. but you still need to allocate jfsmount struct. you're referencing it, and it is not initialized. |
|
From: Hiten P. <hit...@ya...> - 2002-06-24 08:32:47
|
--- Sergey Lyubka <de...@as...> wrote: > Hi Hiten, Hi! :) > few comments about the patch. > > line 187: you're calling chkSuper, > but superblock has not being read into memory yet, > and mout structure has not being alloc-ed. I apologise, but if you have a look at the code for chkSuper() which is in the JFS4BSD repository, (sorry, I didn't include it in the patch because it is not ported yet) then you will notice that it is chkSuper() which does the reading of the superblock into memory; or am I missing a point? > i suggest to move lines starting from 253 (device checking > and allocating mount struct) to the beginning of the function. > > then, you have to alloc the space for the superblock. > I've done that when allocing mount struct : > > line 286, > MALLOC(jmp, struct jfsmount *, sizeof(struct jfsmount) + > sizeof(struct jfs_superblock), M_JFSMNT, M_WAITOK | M_ZERO); > > jmp->sbp = (struct jfs_superblock *) > ((char *) jmp + sizeof(struct jfsmount)) > > then, before suberblock sanity checking, > when devvp is open, read the superblock into memory, > something like > > struct buf *bp = NULL; > bread(devvp, SUPER1_B, DEV_BSIZE, NOCRED, &bp); > bcopy(jmp->sbp, bp->b_data, sizeof(struct jfs_superblock)); I believe this is done by the readSuper() method, which is also in the JFS4BSD CVS repo. It should read the first superblock, and the alternate superblock if the first one is not present. I have renamed readSuper() to jfs_readSuper() in the patch; we need to expand the rawRead() functions used by jfs_readSuper() to the respective bread()/bwrite(); I am in the process of doing that. :) > we allocate 3 inodes during mount: > aggregate 'self' inode (jmp->ipaimap), > filesystem 'self' inode (jmp->ipimap), > and block allocation map inode (jmp->ipbmap). > i think the comment in jfsmoun.h about ipimap inode, should be > changed. it is the 'filesystem' imap inode, not an aggregate one. According to JFS terms, this is what it should be; Greg, what do you say about this, shall we change the comment to say: "fileset inode"? Apart from that, is there anything "missing" in the jfs_mountfs() code, which I should have know about, or any tips or suggestions? Regards. -- Hiten -- <hi...@uk...> __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Sergey L. <de...@as...> - 2002-06-24 08:17:40
|
On Sun, Jun 23, 2002 at 06:53:46PM -0700, Hiten Pandya wrote: > Hi all. > > I have made this little version of my jfs_mount() function, which is based > on the HPFS_mountfs() framework, but none of the original code remains. The > URL for the patch->/dev/null is available at: > > http://www.pittgoth.com/~hiten/jfs/jfs_nmount.patch > > Basically, it is a merge of the jfs_mount() from OS/2 codebase, and the > jfs_mount() from the Linux codebase. I have taken the bits which I found > useful and merged them together. Hi Hiten, few comments about the patch. line 187: you're calling chkSuper, but superblock has not being read into memory yet, and mout structure has not being alloc-ed. i suggest to move lines starting from 253 (device checking and allocating mount struct) to the beginning of the function. then, you have to alloc the space for the superblock. I've done that when allocing mount struct : line 286, MALLOC(jmp, struct jfsmount *, sizeof(struct jfsmount) + sizeof(struct jfs_superblock), M_JFSMNT, M_WAITOK | M_ZERO); jmp->sbp = (struct jfs_superblock *) ((char *) jmp + sizeof(struct jfsmount)) then, before suberblock sanity checking, when devvp is open, read the superblock into memory, something like struct buf *bp = NULL; bread(devvp, SUPER1_B, DEV_BSIZE, NOCRED, &bp); bcopy(jmp->sbp, bp->b_data, sizeof(struct jfs_superblock)); we allocate 3 inodes during mount: aggregate 'self' inode (jmp->ipaimap), filesystem 'self' inode (jmp->ipimap), and block allocation map inode (jmp->ipbmap). i think the comment in jfsmoun.h about ipimap inode, should be changed. it is the 'filesystem' imap inode, not an aggregate one. regards, Sergey |
|
From: Hiten P. <hit...@ya...> - 2002-06-24 01:53:51
|
Hi all. I have made this little version of my jfs_mount() function, which is based on the HPFS_mountfs() framework, but none of the original code remains. The URL for the patch->/dev/null is available at: http://www.pittgoth.com/~hiten/jfs/jfs_nmount.patch Basically, it is a merge of the jfs_mount() from OS/2 codebase, and the jfs_mount() from the Linux codebase. I have taken the bits which I found useful and merged them together. There are some functions, (chkSuper, and updateSuper) which we need to implement. I am not sure how correct || complete my version of jfs_mount() is; maybe Greg or HCH can make a few comments on the patch. :-) Thanks in Advance. Regards. -- Hiten Pandya -- <hi...@uk...> __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
