[Savannah-hackers] Re: submission of Snort Intrusion Detection System - savannah.nongnu.org
Mathieu Roy writes: > Personally, I think that Savannah is development platform and > shouldn't be considered as a cheap mirror. > Loic, Jaime, do you agree or, a contrario, think that the Savannah > mission should include mirroring? Since this request is rare, I would say yes, as long as the mirrored data fits the Savannah requirements. It might be a problem if people start to massively use Savannah as a remote disk space only. Cheers, -- Sauvez le droit d'auteur Loic Dachary http://eucd.info/ [EMAIL PROTECTED] Tel : 33 1 42 76 05 49 ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Re: submission of RFID - savannah.nongnu.org
Hi, I accepted the project I submitted. People can find the matching distribution at http://www.lri.fr/~dachary/rfid/. I'm also willing to take my shift in the moderation process again. Cheers, [EMAIL PROTECTED] writes: > > A package was submitted to savannah.nongnu.org > This mail was sent to [EMAIL PROTECTED], [EMAIL PROTECTED] > > > Loic Dachary <[EMAIL PROTECTED]> described the package as follows: > License: gpl > Other License: > Package: RFID > System name: rfid > Type: non-GNU > > Description: > The rfid library is a set of C functions to dialog with RFID devices. > RFID transponders are typically found in books. This is the small flat > thing the cashier clears or removes and that will ring bells if you > walk thru the doors without paying the bill. The doors are equiped > with RFID readers whose antenna will read RFID transponders. The rfid > library is designed and tested to work with the Series 6000- HF-I RFID > Evaluation Kit. > > > Other Software Required: > POSIX Operating system > > Other Comments: > > > > > > * In case you have to register your project again * > Please be aware that if your registration does not fulfill all therequirements, the > Savannah administrators may ask you to register your project again. > You can use the following url to do a new registration starting > with the values used in this registration process. > Copy and paste AS ONE SINGLE URL the following content : > RERegistration-URL-BEGIN- > http://savannah.nongnu.org/register/basicinfo.php?re_purpose=The rfid library is a > set of C functions to dialog with RFID devices. > RFID transponders are typically found in books. This is the small flat > thing the cashier clears or removes and that will ring bells if you > walk thru the doors without paying the bill. The doors are equiped > with RFID readers whose antenna will read RFID transponders. The rfid > library is designed and tested to work with the Series 6000- HF-I RFID > Evaluation Kit. > &re_require_sw=POSIX Operating > system&re_comments=&re_full_name=RFID&re_unix_name=rfid > RERegistration-URL-END--- > -- Sauvez le droit d'auteur Loic Dachary http://eucd.info/ [EMAIL PROTECTED] Tel : 33 1 42 76 05 49 ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Re: submission of RFID - savannah.nongnu.org
Mathieu Roy writes: > Ok, so you'll take the next week I guess? > (next loic, then jaime, then me) Ok. -- Sauvez le droit d'auteur Loic Dachary http://eucd.info/ [EMAIL PROTECTED] Tel : 33 1 42 76 05 49 ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Re: subversions break down
Paul Fisher writes: > savannah died on Saturday morning and Monday morning. Nothing of > interest was on the serial console. Has anything been changed > recently on savannah? Not that I know. -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 12 bd Magenta http://www.eucd.info/ [EMAIL PROTECTED] 75010Paris T: 33 1 42 45 07 97 [EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] subversions lossage
Hi, I'm going to switch from the ramfs file system (too small because too many simultaneous cvs pserver) to a dedicated ext2 partition. I bet on the fact that the problem we experienced when using /tmp was linked to the specific behaviour of ext3 file systems. I'll let you know how it goes. -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 12 bd Magenta http://www.eucd.info/ [EMAIL PROTECTED] 75010Paris T: 33 1 42 45 07 97 [EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Re: subversions lossage
Hi,
After a few minutes only, the ext2 partition shows:
/dev/hda3 2071416551212 1414980 29% /tmpcvs
which suggests that the ram file system is no longer big
enough to hold the temporary data necessary to run pserver. The disk
I/O did not become histerical and the load average remained stable
(although high : ~6). However, after looking into the temporary
directories, it shows that some people are using something like:
cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot co .
and this checks out *all* Savannah CVS trees (except private
ones). That "hole" was not too much of a problem until now and was
kept for backward compatibility purposes. At this point in time, I
guess it's not unreasonable to remove this possibily.
I moved /cvsroot/CVSROOT to /cvsroot/.CVSROOT-moved-by-loic-2003-06-13
If, after all, /tmpcvs is populated with less than 100MB in average,
we could switch back to using /mnt/ramfs. However, if it turns out that
using an ext2 partition solves the disk overload problem we had with ext3
partitions, I suggest we keep it that way. We could use some mount options
to further enhance the performances of the /tmpcvs partition, such as
-o async. But I'm not an expert on this matter an I guess rao knows better.
Cheers,
Loic Dachary writes:
>
> Hi,
>
> I'm going to switch from the ramfs file system (too small
> because too many simultaneous cvs pserver) to a dedicated ext2
> partition. I bet on the fact that the problem we experienced when
> using /tmp was linked to the specific behaviour of ext3 file systems.
>
> I'll let you know how it goes.
>
> --
> Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED]
> 12 bd Magenta http://www.eucd.info/ [EMAIL PROTECTED]
> 75010Paris T: 33 1 42 45 07 97 [EMAIL PROTECTED]
> GPG Public Key: http://www.dachary.org/loic/gpg.txt
___
Savannah-hackers mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Re: subversions lossage
Mathieu Roy writes: > > Journals are actually not useful in this case. By default ext3 write the journal every 5 sec and I reckon this was the reason why writing lots of temporary data in /tmp was generating a high I/O traffic. > But can't it be also > related to the nature of the hardware? One more time I'll talk about > SCSI ;), IDE is known to use lot of CPU when you access a lot to a > disk... I think SCSI would only better cope with the high I/O traffic. However, lots of I/O in this case is not normal nor necessary. -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 12 bd Magenta http://www.eucd.info/ [EMAIL PROTECTED] 75010Paris T: 33 1 42 45 07 97 [EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Re: subversions lossage
Loic Dachary writes: > > Hi, > > After a few minutes only, the ext2 partition shows: > > /dev/hda3 2071416551212 1414980 29% /tmpcvs It turns out that checkout out all /cvsroot creates ~500MB of temporary files and a very deep tree. It took about 5 minutes to delete the guilty temporary tree. At present the load average is back to an acceptable value (~3) and stable. The I/O on the temporary file system (/tmpcvs) are normal although there are more than 10 simultaneous cvs pserver. iostat says: Device:rrqm/s wrqm/s r/s w/s rsec/s wsec/srkB/swkB/s avgrq-sz avgqu-sz await svctm %util /dev/hda 0.00 14.20 130.80 4.80 1046.40 152.00 523.2076.00 8.84 8587216.77 89.82 73.75 100.00 /dev/hda 0.00 15.60 108.20 7.40 865.60 184.00 432.8092.00 9.08 8587218.15 117.30 86.51 100.00 /dev/hda 0.00 32.00 85.80 11.80 686.40 352.00 343.20 176.0010.64 8587220.75 165.57 102.46 100.00 /dev/hda 0.00 63.40 157.40 11.20 1259.20 598.40 629.60 299.2011.02 8587224.37 117.32 59.31 100.00 /dev/hda 0.00 23.60 150.60 7.20 1204.80 246.40 602.40 123.20 9.20 8587216.73 76.93 63.37 100.00 /dev/hda 0.00 4.60 72.00 6.20 576.00 86.40 288.0043.20 8.47 8587216.35 144.76 127.88 100.00 /dev/hda 0.00 8.40 88.60 6.80 708.80 123.20 354.4061.60 8.72 8587196.53 131.66 104.82 100.00 /dev/hda 0.00 3.00 208.80 8.60 1670.40 94.40 835.2047.20 8.12 8587196.25 53.73 46.00 100.00 /dev/hda 0.00 2.60 211.60 9.00 1691.20 92.80 845.6046.40 8.09 8587200.05 70.17 45.33 100.00 I suggest we keep the current setup and see what happens. -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 12 bd Magenta http://www.eucd.info/ [EMAIL PROTECTED] 75010Paris T: 33 1 42 45 07 97 [EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
[Savannah-hackers] Stale CVS locks
Hi, There were two stale cvs locks (most certainly because of the crash/hang problems), one for gnue and one for gcc. I removed them. Cheers, -- Loic Dachary http://www.dachary.org/ [EMAIL PROTECTED] 12 bd Magenta http://www.eucd.info/ [EMAIL PROTECTED] 75010Paris T: 33 1 42 45 07 97 [EMAIL PROTECTED] GPG Public Key: http://www.dachary.org/loic/gpg.txt ___ Savannah-hackers mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/savannah-hackers
