Possible FC2 inclusions from fedora.us

[Warren Togami]

I was asked to prepare a small list of packages to possibly move from 
fedora.us into Fedora Core 2.  I propose the following packages for 
discussion of merits.  If they are not chosen for FC2, they will be in 
FC2 Extras at fedora.redhat.com as will the rest of fedora.us packages.


>  ddrescue 
     dd-like tool but doesn't die on I/O errors
         useful if the tool is already installed when you need to attempt
         data recovery?
         Tiny!

>  bonnie++ 
     excellent burn-in stability test for disk/filesystem
     This tool has saved me lots of potential headache and downtime by
     testing and crashing failing hardware or bad kernels before putting
     servers into production.
     Tiny!

>  iptstate 
There is some disagreements to include it in Core or not.  Everyone 
agrees that it is a really nice tool though.
Tiny!


>  pyzor
>      python-based anti-spam system, automatically augments
>      spamassassin scoring power 

Does anyone object to pyzor?  It is an incredibly simple way of making 
spamassassin score more accurately.  The python source appears fairly 
clean and compact, complete with unit tests.  There have not been any 
pyzor releases since September 2002 and watching the mailing list, I 
have not seen anything that looks like a confirmed pyzor bug in all this 
time.

One possible blocker might be that it was not tested on python-2.3 yet.


>  perl-Digest-Nilsimsa
>      Needed for perl-Razor-Agent
>  perl-Razor-Agent 
      perl-based anti-spam system, easily augments spamassassin scoring 
power.  Far more effective in scoring than pyzor, but a bit more 
complicated due to the larger amount of code and dependency.

>  perl-RPM-Specfile 
      generates mostly proper SRPMS out of
any perl CPAN module


>  scribus
>  scribus-i18n-en 
      Popular desktop publishing software
      Target for 1.1.5 coordinating with upstream developers if this is 
accepted into Core.  Otherwise it can go into Extras anytime.

Warren Togami
wtogami(a)redhat.com

[Michael Schwendt]

On Sun, 25 Jan 2004 00:10:50 -1000, Warren Togami wrote:

>   > scribus
>   > scribus-i18n-en
>        Popular desktop publishing software
>        Target for 1.1.5 coordinating with upstream developers if this is 
>  accepted into Core.  Otherwise it can go into Extras anytime. 
Note that LittleCMS (lcms) is one of Scribus' dependencies.

--

[Iain Wade]

>  > ddrescue
>  
>      dd-like tool but doesn't die on I/O errors
>          useful if the tool is already installed when you need to attempt
>          data recovery?
>          Tiny! 
"dd conv=noerror" should do the same thing?

>  > iptstate
>  
>  There is some disagreements to include it in Core or not.  Everyone 
>  agrees that it is a really nice tool though.
>  Tiny! 
"watch cat /proc/net/ip_conntrack" seems to be just as powerfull?

>  > perl-RPM-Specfile
>       generates mostly proper SRPMS out of any perl CPAN module 
hugely convenient, yes please. :)

glancing through the package list the only other thing there which I
use commonly and would be interested in seeing promoted up would be
rdiff-backup, however I am more a fan of the small-core Fedora so
I won't suggest it.

Regards,
--Iain

[Ronny Buchmann]

On Sunday 25 January 2004 12:04, Iain Wade wrote:
>  > > ddrescue
>  >
>  >     dd-like tool but doesn't die on I/O errors
>  >         useful if the tool is already installed when you need to attempt
>  >         data recovery?
>  >         Tiny!
>
>  "dd conv=noerror" should do the same thing? 
You've never needed to
try it, I think.

ddrescue is really useful (and should also be on the rescue image), the 
progress/speed display is very helpful.

The dd_rhelp (http://www.kalysto.ath.cx/utilities/dd_rhelp/) script should 
probably be included as well.

-- 
http://LinuxWiki.org/RonnyBuchmann

[Alan Cox]

On Sun, Jan 25, 2004 at 02:58:49PM +0100, Ronny Buchmann wrote:
>  > "dd conv=noerror" should do the same thing?
>  You've never needed to try it, I think. 
Explain further ?

And is dd_recover using O_DIRECT when it can ?

[Ronny Buchmann]

On Sunday 25 January 2004 15:55, Alan Cox wrote:
>  On Sun, Jan 25, 2004 at 02:58:49PM +0100, Ronny Buchmann wrote:
>  > > "dd conv=noerror" should do the same thing?
>  >
>  > You've never needed to try it, I think.
>
>  Explain further ? 
Ok, after readimg some source (and dd(1) again) I found the
explanation, one 
needs "dd conv=noerror,sync" (it doesn't do the same as dd_rescue but comes

close-by)

But what is really missing from dd is a progress indicator. ... Oh, this 
SIGUSR1 is nowhere documented :(

So what's left:
 - dd_rescue changes block size automatically (so it reads more data than dd 
or is faster, depending on the blocksize you would use for dd)

>  And is dd_recover using O_DIRECT when it can ? 
No, should it?
(I don't see what problem this would solve.)

-- 
ronny

[Alan Cox]

On Mon, Jan 26, 2004 at 01:29:15PM +0100, Ronny Buchmann wrote:
>  So what's left:
>   - dd_rescue changes block size automatically (so it reads more data than dd 
>  or is faster, depending on the blocksize you would use for dd)
>  
>  > And is dd_recover using O_DIRECT when it can ?
>  No, should it? (I don't see what problem this would solve.) 
It can help avoid errors where readahead or I/O merging does a large
read including an error but smaller reads around the bad block might
succeed

[Steven Pritchard]

On Mon, Jan 26, 2004 at 07:38:18AM -0500, Alan Cox wrote:
>  It can help avoid errors where readahead or I/O merging does a large
>  read including an error but smaller reads around the bad block might
>  succeed 
dd_rescue handles that by using a large block size until it hits an
error, then retrying with a small block size.

I've had to use it a few times.  It works really well.

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com             http://www.kspei.com/
Phone: [phone]               Mobile: [phone]

[Hoyt]

On Monday 26 January 2004 12:07 pm, Steven Pritchard wrote:
>  dd_rescue handles that by using a large block size until it hits an
>  error, then retrying with a small block size.
>
>  I've had to use it a few times.  It works really well. 
How did you get it to compile on Fedora?

-- 
Hoyt

[Alan Cox]

On Mon, Jan 26, 2004 at 11:07:06AM -0600, Steven Pritchard wrote:
>  dd_rescue handles that by using a large block size until it hits an
>  error, then retrying with a small block size.
>  
>  I've had to use it a few times.  It works really well. 
The file system may still do smart stuff like merging requests. Also only
raw I/O to disks really lets you get down to the media block size not the
fs block size (eg losing 512 bytes not 4k). Thats normally only an issue
with floppies because the 'real' blocksize of a hard disk is now typically
8-32K

[Ronny Buchmann]

On Monday 26 January 2004 18:58, Alan Cox wrote:
>  On Mon, Jan 26, 2004 at 11:07:06AM -0600, Steven Pritchard wrote:
>  > dd_rescue handles that by using a large block size until it hits an
>  > error, then retrying with a small block size.
>  >
>  > I've had to use it a few times.  It works really well.
>
>  The file system may still do smart stuff like merging requests. Also only 
It's
usually used for reading from block devices (disks).
>  raw I/O to disks really lets you get down to the media block size not
> the
>  fs block size (eg losing 512 bytes not 4k). Thats normally only an issue
>  with floppies because the 'real' blocksize of a hard disk is now typically
>  8-32K 
Does the kernel do read-ahead in the block layer or in vfs?

-- 
http://LinuxWiki.org/RonnyBuchmann

[Alan Cox]

On Mon, Jan 26, 2004 at 07:21:58PM +0100, Ronny Buchmann wrote:
>  > The file system may still do smart stuff like merging requests.
> Also only
>  It's usually used for reading from block devices (disks). 
Issue a few reads and the kernel will begin readahead, it will also merge
the read and readahead into one I/O at times.

>  > with floppies because the 'real' blocksize of a hard
> disk is now typically
>  > 8-32K
>  Does the kernel do read-ahead in the block layer or in vfs? 
Yes 8)

Some of the file systems (especially xfs) do quite smart readahead tricks,
others use the basic facilities of the block layer and others still like
jffs and nfs don't use the block layer but their own ways of handling
this stuff.

[Chadley Wilson]

On Mon, 2004-01-26 at 20:27, Alan Cox wrote:
>  On Mon, Jan 26, 2004 at 07:21:58PM +0100, Ronny Buchmann wrote:
>  > > The file system may still do smart stuff like merging requests. Also only
>  > It's usually used for reading from block devices (disks).
>  
>  Issue a few reads and the kernel will begin readahead, it will also merge
>  the read and readahead into one I/O at times.
>  
>  > > with floppies because the 'real' blocksize of a hard disk is now
> typically
>  > > 8-32K
>  > Does the kernel do read-ahead in the block layer or in vfs?
>  
>  Yes 8)
>  
>  Some of the file systems (especially xfs) do quite smart readahead tricks,
>  others use the basic facilities of the block layer and others still like
>  jffs and nfs don't use the block layer but their own ways of handling
>  this stuff.
>  
>   
Is DMA going to be enabled in FC2?
Chad

[Ronny Buchmann]

On Sunday 25 January 2004 15:55, Alan Cox wrote:
>  And is dd_recover using O_DIRECT when it can ? 
My last
question, I think: When can O_DIRECT not be used?

-- 
http://LinuxWiki.org/RonnyBuchmann

[Alan Cox]

On Mon, Jan 26, 2004 at 11:13:44PM +0100, Ronny Buchmann wrote:
>  > And is dd_recover using O_DIRECT when it can ?
>  My last question, I think: When can O_DIRECT not be used? 
When open with O_DIRECT fails. Its a "please can I have this" option
that not all file systems support

[Ronny Buchmann]

On Monday 26 January 2004 23:29, Alan Cox wrote:
>  On Mon, Jan 26, 2004 at 11:13:44PM +0100, Ronny Buchmann wrote:
>  > > And is dd_recover using O_DIRECT when it can ?
>  >
>  > My last question, I think: When can O_DIRECT not be used?
>
>  When open with O_DIRECT fails. Its a "please can I have this" option
>  that not all file systems support 
So for (block) devices it will aways work?

[Gene C.]

On Sunday 25 January 2004 05:10, Warren Togami wrote:
>   > ddrescue
>
>       dd-like tool but doesn't die on I/O errors
>           useful if the tool is already installed when you need to attempt
>           data recovery?
>           Tiny! 
Check.

>   > bonnie++
>
>       excellent burn-in stability test for disk/filesystem
>       This tool has saved me lots of potential headache and downtime by
>       testing and crashing failing hardware or bad kernels before putting
>       servers into production.
>       Tiny! 
Check.

>   > iptstate
>
>  There is some disagreements to include it in Core or not.  Everyone
>  agrees that it is a really nice tool though.
>  Tiny! 
What does it do?
-- 
Gene