ssic-linux-devel Mailing List for OpenSSI Clusters for Linux
Brought to you by:
brucewalker,
rogertsang
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(53) |
Aug
(7) |
Sep
(38) |
Oct
(51) |
Nov
(73) |
Dec
(63) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(26) |
Feb
(70) |
Mar
(69) |
Apr
(51) |
May
(79) |
Jun
(71) |
Jul
(33) |
Aug
(86) |
Sep
(71) |
Oct
(64) |
Nov
(59) |
Dec
(76) |
2003 |
Jan
(142) |
Feb
(78) |
Mar
(98) |
Apr
(98) |
May
(35) |
Jun
(51) |
Jul
(70) |
Aug
(83) |
Sep
(27) |
Oct
(57) |
Nov
(82) |
Dec
(53) |
2004 |
Jan
(70) |
Feb
(16) |
Mar
(217) |
Apr
(302) |
May
(141) |
Jun
(213) |
Jul
(138) |
Aug
(90) |
Sep
(96) |
Oct
(193) |
Nov
(218) |
Dec
(348) |
2005 |
Jan
(162) |
Feb
(259) |
Mar
(287) |
Apr
(281) |
May
(155) |
Jun
(106) |
Jul
(73) |
Aug
(190) |
Sep
(131) |
Oct
(79) |
Nov
(87) |
Dec
(81) |
2006 |
Jan
(25) |
Feb
(28) |
Mar
(31) |
Apr
(24) |
May
(49) |
Jun
(34) |
Jul
(57) |
Aug
(40) |
Sep
(27) |
Oct
(31) |
Nov
(59) |
Dec
(50) |
2007 |
Jan
(35) |
Feb
(41) |
Mar
(27) |
Apr
(42) |
May
(13) |
Jun
(40) |
Jul
(59) |
Aug
(86) |
Sep
(13) |
Oct
(23) |
Nov
(14) |
Dec
(28) |
2008 |
Jan
(30) |
Feb
(3) |
Mar
(9) |
Apr
(43) |
May
(32) |
Jun
(43) |
Jul
(23) |
Aug
(17) |
Sep
(14) |
Oct
(49) |
Nov
(6) |
Dec
(9) |
2009 |
Jan
(81) |
Feb
(5) |
Mar
(52) |
Apr
(13) |
May
(6) |
Jun
(3) |
Jul
(10) |
Aug
(7) |
Sep
(2) |
Oct
(28) |
Nov
(5) |
Dec
(6) |
2010 |
Jan
(25) |
Feb
(26) |
Mar
(27) |
Apr
(34) |
May
(9) |
Jun
(1) |
Jul
(16) |
Aug
(2) |
Sep
(1) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
2011 |
Jan
(6) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2012 |
Jan
|
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Stan C S. <sta...@ra...> - 2016-08-07 18:37:15
|
OpenSSI is a very interesting technology for its time: Locus Computing, Intel, Transmeta and HP labs all gave the SSI (Single-System-Image) code base a chance. The challenges which held back OpenSSI acceptance are: · Fear of SSI model when OpenSSI RPCs have no ‘real’ failure/recovery mechanism; if interconnect fails RPC hangs; that said the predecessor code of OpenSSI powered Intel Paragon supercomputers @ 2000+ nodes, in addition to the TFLOPS machine service/IO nodes, large IBM and Transmeta systems. OpenSSI can shine when your interconnect is reliable. · Issues upstreaming Linux kernel patches: o CFS filesystem was disliked by the Linux community; context specific symlinks were disliked by Linus; not clear on other CFS aspects which were disliked. o rfork(), rexec(), rvfork() were abused by Linux community as the implementation was built on RPCs which had to no clean failure recovery. o Linux-2.6.18 + some x64 work is approximately were OpenSSI faded away; bringing OpenSSI up to current Linux kernel standards would be a large task. o OpenSSI was based on RHEL 4.x and Debian xxx, updates to sys config as OpenSSI is somewhat disruptive w.r.t. use of context specific symlinks which make the booting of a Linux distro work… ‘/etc == /node-num/etc’ thus creating a global /etc which namei resolves to a accessing node specific path. · Node discovery is based on Ethernet broadcast capabilities which not all high performance fabric supported in the node boot phase. For the InfiniBand interconnect implementation I had to use Ethernet as the boot/node discovery fabric. OpenSSI in various flavors was developed and functional in the era before high performance interconnects were widely available outside of commercial system builder designs. Once the industry gets to an on-chip reliable network/interconnect (reliable as processor registers) OpenSSI concepts could become a viable option. The prevailing industry trend is to cluster #’s of independent nodes/systems (private root FS) which all mount a DFS (Lustre or GFS….) to form a cluster; isolating the reliability concerns to a specific node and the cluster wide application. Stan. From: Luke Hindman [mailto:lu...@pl...] Sent: Thursday, August 04, 2016 4:46 PM To: ssi...@li... Subject: [SSI-devel] OpenSSI Project Status Hi, A friend and I were just talking about OpenSSI and we're thinking it might be interesting to explore this technology again. I am curious if any of the OpenSSI developers are still around and subscribed to this list. It would be interesting to know why this project died and whether they feel this approach to clustering might still be useful in 2016. I would appreciate any thoughts or comments. Thanks, --Luke |
From: Luke H. <lu...@pl...> - 2016-08-04 23:45:38
|
Hi, A friend and I were just talking about OpenSSI and we're thinking it might be interesting to explore this technology again. I am curious if any of the OpenSSI developers are still around and subscribed to this list. It would be interesting to know why this project died and whether they feel this approach to clustering might still be useful in 2016. I would appreciate any thoughts or comments. Thanks, --Luke |
From: Brian E. <bri...@ya...> - 2013-03-14 03:41:41
|
http://www.neronecaffe.com/fh/wnliuxyog/aqywdpx=bfr |
From: Amit K. <ami...@gm...> - 2012-07-30 08:29:15
|
Hi All, I am trying to install OpenSSI in my ubuntu 12.04 but not able get right procedude. any one please specify is it possible or not in Ubuntu 12.04? Any one can please give me the information about Hardware we need. is it require two NIC card enable machine for first node? Which linux disribution is best for this software. i need installation procedure so that i can install in my system Thanks in advance. ~Amit Khatri |
From: Roger T. <rog...@gm...> - 2012-04-01 18:29:09
|
Hi Brian, http://openssi.org/cgi-bin/view?page=openssi.html That webpage has links to the Debian releases with instructions. John has been maintaining OpenSSI for Debian but he has been busy lately. If memory serves me right devfs is deprecated and udev is newer. That is why we are using udev. Not only that, we want to port OpenSSI to kernel-2.6.18 or newer and 2.6.18 uses udev. We want 2.6.18 so we can upgrade to RHEL5 and the next Debian distro. Latest status is OpenSSI is "pretty" stable on the existing kernel 2.6.11 and perhaps also on John's 2.6.14 too. However I hear we are stuck with initrd for the time being because the developers who ported 2.6.9-ssi to 2.6.11 had trouble with initramfs. You might run into rare warnings with file locks if your application competes locally with remote file locks especially with preemptive kernel. So we still need to implement proper sequencing within the kernel for clustered file locks. The native 2.6.11 kernel uses the big kernel lock which is only good enough for local file locks. After having spent some time stabilizing / improving 2.6.11-ssi for SMP I ported the userspace and kernel in OpenSSI for Fedora Core 3 to Red Hat Enterprise 4 (using kernel source code from CentOS 4) and was able to boot the cluster. The original RHEL4 kernel is already super patched, so I must have missed something while porting. In OpenSSI for RHEL4 remove exec does not work - aka. `onnode 2 cat`. Think I need to trace sys_rexecve() and see what is going on inside the kernel. I haven't got to doing that yet. Regards, Roger On Fri, Mar 16, 2012 at 11:06 AM, Brian Empson <bri...@ya...>wrote: > Hello, > > I'd like to help with porting the existing kernel to newer distributions > of debian specifically. What can I do to help and where should I start? I'd > like to see where development is going so far. > > > Regards, > Brian > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Samuele C. <car...@cs...> - 2012-03-19 20:47:31
|
On 03/19/2012 09:14 PM, Black, Rick wrote: > Hi Brian, > > > > I very recently joined the list. I’ve been watching SSIC for quite a while. I had it running about 8 years ago and I liked what I saw. > > > > Best Regards, > > > > Richard > I'm on the list as well! Just a sympathizer, I couldn't manage to get it working properly for me yet, but I'm willing to help :) Sam -- |-- | Samuele Carli |-- | Contacts: | | Home page : www.csspace.net | E-mail : carlisamuele _at_ csspace.net | Icq : 60401601 | MSN : wo...@ho... (no e-mails here!) | Skype : wohthan | jabber/gtalk: wo...@gm... |-- |
From: Black, R. <ric...@hp...> - 2012-03-19 20:14:56
|
Hi Brian, I very recently joined the list. I've been watching SSIC for quite a while. I had it running about 8 years ago and I liked what I saw. Best Regards, Richard From: Brian Empson [mailto:bri...@ya...] Sent: Saturday, March 17, 2012 11:01 AM To: ssi...@li... Subject: [SSI-devel] Anybody home? Does anyone even use this list anymore? :3 |
From: Brian E. <bri...@ya...> - 2012-03-19 18:32:51
|
Confused as to why OpenSSI uses udev but are using an initrd as opposed to initramfs. On boot it fails with "unknown filesystem devfs". Installing openssi on debian etch removes the devfsd package and installs udev for some reason I cannot understand. Why would you use and initrd with udev if initrd wants to use devfs, moreover, why would you not compile devfs support into a kernel that uses an initrd image? There's no instructions that tell me to do anything different...I'd like to at least have a running OpenSSI machine before I start development! :) My NIC module is in the initrd lib/modules, still doesnt load it for some reason, however. This is getting rediculous, I must have spent 4 days and 30+ hours trying to get the damn thing to boot. I mean, it sees the NIC in the directory, the kernel (stock debian) can use it and the ssi kernel has the module in it's modules folder. I don't know what else you have to do to get it to work! Also, on compiling the kernel to attempt to add devfs support: Compiling the kernel fails with any source package from apt-get or cvs: include/linux/pagemap.h: In function `fault_in_pages_writeable': include/linux/pagemap.h:208: error: `__put_user_lcl' undeclared (first use in this function) include/linux/pagemap.h:208: error: (Each undeclared identifier is reported only once include/linux/pagemap.h:208: error: for each function it appears in.) include/linux/pagemap.h:218:48: macro "__put_user_lcl" passed 3 arguments, but takes just 2 include/linux/pagemap.h:228:34: macro "__get_user_lcl" passed 3 arguments, but takes just 2 include/linux/pagemap.h: In function `fault_in_pages_readable': include/linux/pagemap.h:228: error: `__get_user_lcl' undeclared (first use in this function) include/linux/pagemap.h:234:42: macro "__get_user_lcl" passed 3 arguments, but takes just 2 include/linux/pagemap.h:225: warning: unused variable `c' I've since fixed these errors but there are still MORE errors! What is the proper compiler version, mine is 2.95.3. (Maybe it's my compiler? Although newer versions complain about the same thing.) I must have "patched" over 30 files and still going strong :3 If I could just get the kernel to compile, I could continue troubleshooting this thing. Regards, Brian Looking through the source I'm trying to patch things as I go but the deeper I get the more it looks like it's unfinished, even in the debian source packag |
From: marius a. p. <ma...@gm...> - 2012-03-18 08:36:41
|
On Sun, Mar 18, 2012 at 12:09 AM, Brian Empson <bri...@ya...> wrote: > Cool. Im working on a patch for the cvs code I'm interested in the database clustering area (I want to run Firebird on a ssi cluster) Also i can help with debian testing and patching if needed |
From: Brian E. <bri...@ya...> - 2012-03-17 22:09:47
|
Cool. Im working on a patch for the cvs code Sent from my Droid Charge on Verizon 4G LTE ------Original Message------ From: Dave Paris <dp...@w3...> To: "Brian Empson" <bri...@ya...> Date: Saturday, March 17, 2012 5:31:53 PM GMT-0400 Subject: Re: [SSI-devel] Anybody home? It does see periodic traffic. On Sat, Mar 17, 2012 at 12:01 PM, Brian Empson <bri...@ya...> wrote: > Does anyone even use this list anymore? :3 > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |
From: Brian E. <bri...@ya...> - 2012-03-17 16:01:18
|
Does anyone even use this list anymore? :3 |
From: Brian E. <bri...@ya...> - 2012-03-16 16:04:06
|
Have any of you looked into making your own linux distro a-la Linux from Scratch? I think it would make things easier for the end user if everything was consistent distro wise. Package managers can be configured later, no? Regards, Brian |
From: Brian E. <bri...@ya...> - 2012-03-16 15:06:31
|
Hello, I'd like to help with porting the existing kernel to newer distributions of debian specifically. What can I do to help and where should I start? I'd like to see where development is going so far. Regards, Brian |
From: John H. <john@Calva.COM> - 2011-12-21 14:50:57
|
On 16/11/11 18:22, Roger Tsang wrote: > Hi, > > The latest CVS check-in fixes a potential corruption at CFS server due > to recursion. The bug was CFS inherited the backing device info of > the backing file system. The Linux VM is re-entrant at > balance_dirty_pages() and can call CFS recursively when the backing > device info are the same on both file systems. > > CFS -> VM -> PFS -> VM -> CFS -> VM -> PFS ... > > The Linux VM may not call this far down and may not traverse file > systems exactly as shown but if this happens you may get stack > overflow, etc. Interesting. Does this mean OpenSSI might work with 4K stacks now? |
From: Roger T. <rog...@gm...> - 2011-11-16 17:22:19
|
Hi, The latest CVS check-in fixes a potential corruption at CFS server due to recursion. The bug was CFS inherited the backing device info of the backing file system. The Linux VM is re-entrant at balance_dirty_pages() and can call CFS recursively when the backing device info are the same on both file systems. CFS -> VM -> PFS -> VM -> CFS -> VM -> PFS ... The Linux VM may not call this far down and may not traverse file systems exactly as shown but if this happens you may get stack overflow, etc. The fix should increase interactiveness and decrease latency since the VM no longer makes recursive calls at balance_dirty_pages(). -Roger |
From: SourceForge.net <no...@so...> - 2011-06-20 23:52:15
|
Feature Requests item #3323515, was opened at 2011-06-20 23:52 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405837&aid=3323515&group_id=32541 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Boot / Init Group: Next Release (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Openssi live CD Initial Comment: I have seen a few live cluster CD's but none that work off of a ssi type with" single process space". It would be a great enhancement to Openssi because a live CD can run without making changes to the operating system, and be set up quicker and easier than having to configure it for a currently running operating system. A good example of a live CD is "PelicanHPC" you can have a look at it here http://idea.uab.es/mcreel/ParallelKnoppix/. I had it set up in minutes; however it does not have single process space capability as far as I know. Please consider creating a Openssi live cluster CD :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405837&aid=3323515&group_id=32541 |
From: SourceForge.net <no...@so...> - 2011-05-10 02:36:28
|
Bugs item #2010447, was opened at 2008-07-04 09:19 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405834&aid=2010447&group_id=32541 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Filesystem Group: default Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Hughes (hughesj) Assigned to: Roger Tsang (rogertsang) Summary: OpenSSI fails the glibc tst-atime test Initial Comment: CFS doesn't keep the atime (last accessed time) field up to date. This is a known limitation, I'm just reporting it here so it doesn't get forgotten about. Maybe as a workaround we could pretend that cfs filesystems were mounted with the noatime option? To reproduce: $ cc tst-atime.c $ ./a.out atime has not changed ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-05-10 02:36 Message: Tracker.. Huh, really? :) ---------------------------------------------------------------------- Comment By: Roger Tsang (rogertsang) Date: 2010-11-13 05:05 Message: Testing a patch. So far successfully tested at server. ---------------------------------------------------------------------- Comment By: John Hughes (hughesj) Date: 2008-10-24 10:23 Message: What's very bizarre is that this sometimes works on nodes other than the one where the underlying filesystem is mounted, the access time seems to get changed the first time a file is read, but not afterwards. ---------------------------------------------------------------------- Comment By: John Hughes (hughesj) Date: 2008-10-19 16:04 Message: Actually the: rootfs / rootfs stuff is not specific to OpenSSI. What happens in statvfs is it looks for a mountpoint with the same filesystem type as the file it's been given (so it's looking for ext2/ext3) but from /proc our fs shows up as cfs, so it doesn't see that it's the same one. Later on it retries without the type, but this time around the "rootfs / rootfs" one matches and that doesn't have the flags. ---------------------------------------------------------------------- Comment By: John Hughes (hughesj) Date: 2008-10-19 15:32 Message: Simple idea, just do this at user level by remounting the fs with an explicit noatime option: mount -o remount,noatime / doesn't work because statvfs reads /proc/mounts to find the mount options and some of the weird crud we have hanging around confuses it: # cat /proc/mounts rootfs / rootfs rw 0 0 /dev2/root2 / cfs rw,noatime,chard,node=1 0 0 ... Which is the real root? Apparently statvfs thinks it's the first one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405834&aid=2010447&group_id=32541 |
From: Roger T. <rog...@gm...> - 2011-02-19 20:35:10
|
FYI there is an error with CVS syncmail, so recent check-in activity did not get to the ssic-linux-checkins mailing list. -Roger Checking in cluster/ssi/vproc/nd_object.c; /cvsroot/ssic-linux/openssi/kernel/cluster/ssi/vproc/nd_object.c,v <-- nd_object.c new revision: 1.8; previous revision: 1.7 done Mailing ssi...@li...... Generating notification message... Generating notification message... done. Mailing ssi...@li...... Generating notification message... Traceback (most recent call last): File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ? main() File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 426, in main contextlines, fromhost, replyto) File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 223, in blast_mail conn.connect(MAILHOST, MAILPORT) File "/usr/lib64/python2.4/smtplib.py", line 306, in connect raise socket.error, msg socket.error: (111, 'Connection refused') |
From: SourceForge.net <no...@so...> - 2011-01-24 02:41:11
|
Feature Requests item #3164458, was opened at 2011-01-24 02:41 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405837&aid=3164458&group_id=32541 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: compiing on custum distro. Initial Comment: I wanted to compile this on linux from scratch but the source is distro specific. Please make it easer to get the source code before it is compiled to a binary for a specific linux distro. that does not seem very open source to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405837&aid=3164458&group_id=32541 |
From: Samuele C. <car...@cs...> - 2011-01-18 10:36:14
|
On 01/14/2011 04:43 PM, John Hughes wrote: > On 14/01/11 14:51, Samuele Carli wrote: >> Not a HASH reference at /sbin/mkboottab line 46. >> >> Error generating boottab. Try again >> > AArgh! > > When I fixed the problem for i686 I obviously forgot to upload the fixed > version for amd64. > > I'll try and see if I can fix it this weekend. > Cool, I'm really looking forward for that, thank you very much! If you need any help anyhow... let me know :) Have a nice day, SC -- |-- | Samuele Carli |-- | Contacts: | | Home page : www.csspace.net | E-mail : carlisamuele _at_ csspace.net | Icq : 60401601 | MSN : wo...@ho... (no e-mails here!) | Skype : wohthan | jabber/gtalk: wo...@gm... |-- |
From: John H. <john@Calva.COM> - 2011-01-14 15:43:43
|
On 14/01/11 14:51, Samuele Carli wrote: > Not a HASH reference at /sbin/mkboottab line 46. > > Error generating boottab. Try again > AArgh! When I fixed the problem for i686 I obviously forgot to upload the fixed version for amd64. I'll try and see if I can fix it this weekend. |
From: Samuele C. <car...@cs...> - 2011-01-14 14:18:42
|
Hi, working with a fresh install (amd64), i'm incurring in the same problem previously reported for i686: while installing linux-image-2.6.12-ssi-amd64_1.9.6-13_amd64.deb it happens: Running depmod. Finding valid ramdisk creators. Using /usr/sbin/mkinitrd to build the ramdisk. cpio: initrd/lib/libcluster.so.0 not created: newer or same age version exists cpio: initrd/lib/libc.so.6 not created: newer or same age version exists Not a HASH reference at /sbin/mkboottab line 46. Error generating boottab. Try again run-parts: /etc/mkinitrd/scripts/tabonly-install exited with return code 1 /usr/sbin/mkinitrd failed to create initrd image. Failed to create initrd image. ... and so on. What to do? Thank you, have a nice day! SC -- |-- | Samuele Carli |-- | Contacts: | | Home page : www.csspace.net | E-mail : carlisamuele _at_ csspace.net | Icq : 60401601 | MSN : wo...@ho... (no e-mails here!) | Skype : wohthan | jabber/gtalk: wo...@gm... |-- |
From: Roger T. <rog...@gm...> - 2011-01-02 01:19:47
|
When porting to a newer Linux distribution you need to: A) port the user / system utilities B) port the kernel To port the kernel you "basically" do the following: 1) Generate diff against the Linux kernel that OpenSSI is based on. 2) Apply diff against new Linux kernel. 3) Fix patch rejects. 4) Fix compilation issues. 5) Fix runtime issues. You may need to modify OpenSSI for the new kernel. So it would help to research changes to various subsystems and API in the newer kernel that may affect OpenSSI. SF.net SVN repository contains Stan's attempt to port OpenSSI to linux-2.6.18. -Roger On Sat, Jan 1, 2011 at 12:32 AM, Mulyadi Santosa <mul...@gm...>wrote: > On Sat, Jan 1, 2011 at 03:33, Roger Tsang <rog...@gm...> wrote: > > I am aware of that. You will know when we get there. > > If someone wanna help in this RHEL port, what should he/she do? I'll > see what I can do although I can't commit anything firmly right > now.... > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > |
From: SourceForge.net <no...@so...> - 2010-11-13 05:05:28
|
Bugs item #2010447, was opened at 2008-07-04 05:19 Message generated for change (Comment added) made by rogertsang You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405834&aid=2010447&group_id=32541 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Filesystem Group: default Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Hughes (hughesj) >Assigned to: Roger Tsang (rogertsang) Summary: OpenSSI fails the glibc tst-atime test Initial Comment: CFS doesn't keep the atime (last accessed time) field up to date. This is a known limitation, I'm just reporting it here so it doesn't get forgotten about. Maybe as a workaround we could pretend that cfs filesystems were mounted with the noatime option? To reproduce: $ cc tst-atime.c $ ./a.out atime has not changed ---------------------------------------------------------------------- >Comment By: Roger Tsang (rogertsang) Date: 2010-11-13 00:05 Message: Testing a patch. So far successfully tested at server. ---------------------------------------------------------------------- Comment By: John Hughes (hughesj) Date: 2008-10-24 06:23 Message: What's very bizarre is that this sometimes works on nodes other than the one where the underlying filesystem is mounted, the access time seems to get changed the first time a file is read, but not afterwards. ---------------------------------------------------------------------- Comment By: John Hughes (hughesj) Date: 2008-10-19 12:04 Message: Actually the: rootfs / rootfs stuff is not specific to OpenSSI. What happens in statvfs is it looks for a mountpoint with the same filesystem type as the file it's been given (so it's looking for ext2/ext3) but from /proc our fs shows up as cfs, so it doesn't see that it's the same one. Later on it retries without the type, but this time around the "rootfs / rootfs" one matches and that doesn't have the flags. ---------------------------------------------------------------------- Comment By: John Hughes (hughesj) Date: 2008-10-19 11:32 Message: Simple idea, just do this at user level by remounting the fs with an explicit noatime option: mount -o remount,noatime / doesn't work because statvfs reads /proc/mounts to find the mount options and some of the weird crud we have hanging around confuses it: # cat /proc/mounts rootfs / rootfs rw 0 0 /dev2/root2 / cfs rw,noatime,chard,node=1 0 0 ... Which is the real root? Apparently statvfs thinks it's the first one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=405834&aid=2010447&group_id=32541 |
From: Roger T. <rog...@gm...> - 2010-10-13 15:39:04
|
The CentOS 4 kernel is able to finish initializing, execve and other syscalls work. KDB also works and in my point of view getting the rest of the system going is not that hard compared to porting. So I decided to take a breather. I switched to another sub-project I had going. There are a few sub-projects for OpenSSI. One of them is this CentOS 4 kernel. The other is porting CentOS 4 userspace which is done and I'm just testing. Another sub-project is optimizing the existing OpenSSI code base in the kernel. There were a few items that could be improved. CentOS 5 coming soon.. ;-) On Tue, Oct 12, 2010 at 8:06 PM, Christopher G. Stach II <cg...@ld...>wrote: > ----- Original Message ----- > > Ran into a few issues with KDB. The main issue is the do_int3() > > function prototype in the existing KDB patch is a fastcall which looks > > for arguments in the CPU registers, but the revised int3 trap pushes > > the arguments on the stack. That was a tricky one to catch. > > > > Now it looks like we got a working CentOS 4 kernel for OpenSSI... > > I haven't had time to bang on OpenSSI in a few years, but I'm still > interested. Your announcement seems to have been a dud, but I think it's > great news. Thanks! CentOS 5 next month, right? ;) > > -- > Christopher G. Stach II > http://ldsys.net/~cgs/ <http://ldsys.net/%7Ecgs/> > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > |