Re: max filesize split(1)

[Sebastian Dehne]

 yes, but then it's still irrelevant how big a file the source
 filesystem supports, which was the original question.

The filesystem reference in my original question was meant as an
example. My point was just that split(1) could need an upgrade since it is
not too uncommon anymore to split files which are bigger than 2GB.
That's all. Now, let's skip the fs talk.

regards
Sebastian

Re: max filesize split(1)

[Sebastian Dehne]

Otto,

Thanks for considering it. Here is the patch which worked for me:

#
# BEGIN PATCH SPLIT(1)
#
--- split.c Tue Oct 17 09:19:24 2006
+++ split_new.c Tue Oct 17 09:20:15 2006
@@ -59,7 +59,7 @@

 #define DEFLINE1000/* Default num lines per
file. */

-longbytecnt;   /* Byte count to split on. */
+long long   bytecnt;   /* Byte count to split
on. */
 longnumlines;  /* Line count to split on. */
 int file_open; /* If a file open. */
 int ifd = -1, ofd = -1;/* Input/output file
descriptors. */
@@ -105,7 +105,7 @@
ifd = 0;
break;
case 'b':   /* Byte count. */
-   if ((bytecnt = strtol(optarg, ep, 10)) = 0 ||
+   if ((bytecnt = strtoll(optarg, ep, 10)) = 0 ||
(*ep != '\0'  *ep != 'k'  *ep != 'm'))
errx(EX_USAGE,
%s: illegal byte count, optarg);
@@ -171,7 +171,7 @@
 void
 split1(void)
 {
-   long bcnt;
+   long long bcnt;
int dist, len;
char *C;
#
# END PATCH SPLIT(1)
#



Otto Moerbeek ([EMAIL PROTECTED]) wrote:
 
 send a diff and we will consider it.
 
   -Otto

max filesize split(1)

[Sebastian Dehne]

Hi,

I noticed that split(1) can only handle files which's size = 2GB. I
adjusted my version so that it support larger files.

Why is this limit never increased. I mean, the fs supports much bigger
files. Are there any plans to increased this limit in the future so I 
don't need to patch again when installing a new release?

regards,

Sebastian

Re: max filesize split(1)

[Sebastian Dehne]

Replacing the long data type with a bigger type, so that split(1)
supports bigger splits, works good enough for me.

Sebastian

ICMan ([EMAIL PROTECTED]) wrote:
 My $0.02:
 
 Is there a way to query the file system to find out what the 
 max-file-size is?  If there is, I don't know how to do it, but it could 
 be added to split(1) so that split(1) will handle the largest file 
 allowed by whichever file system is holding the file it is pointing to.
 
 ICMan

Re: pciide: DMA vs. ATA133

[Sebastian Dehne]

Hi Tony,

It turns I'm having the same problem and saw you've done some research.

# dmesg| grep DMA
pciide0 at pci0 dev 15 function 0 VIA VT82C571 IDE rev 0x06: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, DMA mode 2
wd2(pciide0:1:1): using PIO mode 4, DMA mode 2

What exact changes did you make to pciide.c in order to enable
Ultra-DMA? I see the switch at around line 2610 in pciide.c, but cannot
work out how to add PCI_PRODUCT_VIATECH_VT82C571.

I'm running 3.8.

thanks,

Sebastian

Tony Lambiris wrote:
 Man I must need sleep or something... this doesn't fix my problem, I 
 forgot I had the extra case in the switch statement still in pciide.c. 
 That did work, however, adding PCI_PRODUCT_VIATECH_VT82C571 as a case. 
 Like I said before I don't know if this is the right way to do this, but 
 it's a temporary fix for me.
 
 Over and out, sorry again for the noise.
 
 Tony Lambiris wrote:
 Sorry for all the noise, this seems to have fixed it (from NetBSD):

 --- via82c586.c.origMon Sep 12 19:38:35 2005
 +++ via82c586.c Mon Sep 12 20:27:28 2005
 @@ -256,9 +256,10 @@
 reg = pci_conf_read(ph-ph_pc, ph-ph_tag,
 VP3_CFG_PIRQ_REG);
 shift = vp3_cfg_trigger_shift[i];
 -   /* XXX we only upgrade the trigger here */
 if (trigger == IST_LEVEL)
 reg = ~(VP3_CFG_TRIGGER_MASK  shift);
 +   else
 +   reg |= (VP3_CFG_TRIGGER_EDGE  shift);
 pci_conf_write(ph-ph_pc, ph-ph_tag,
 VP3_CFG_PIRQ_REG, reg);
 break;

 Tony Lambiris wrote:

 I forgot to ask, would it be bad practice to just add 
 PCI_PRODUCT_VIATECH_VT82C571 to one of the cases in the switch 
 statement? It seems like this might go a little deeper

 Tony Lambiris wrote:

 Well I thought I knew what the problem was (nope).. I found something 
 interesting though...

 The motherboards that don't setup UDMA properly uses a VIA VT8237 
 ISA for pcib; the one's that setup UDMA properly uses a VIA VT8235 
 ISA. I added some debugging in pciide.c in function apollo_chip_map 
 on the switch statement, and the pcib_id it's switching on is 0x0571, 
 which in pcidevs is VT82C571 IDE. Does that mean somewhere the 
 VT8237 chipset isn't being setup correctly or something?

 I'm a little confused at this juncture, any light that can be shed 
 would be greatly appriciated.

 Thanks.

 Tony Lambiris wrote:

 I (think I) found the problem... I will be posting a patch shortly 
 if I confirm my suspicions.

 Thanks.

 Tony Lambiris wrote:

 We have some motherboards with (what we think) are the same chips 
 and revisions with the same hard drives, but some drives are being 
 detected as DMA and others as ATA133. Here is an example:

 pciide0 at pci0 dev 17 function 1 VIA VT82C571 IDE rev 0x06: 
 ATA133, channel 0 configured to compatibility, channel 1 configured 
 to compatibility
 wd0 at pciide0 channel 0 drive 0: WDC WD800BB-75JHC0
 wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5

 pciide0 at pci0 dev 15 function 0 VIA VT82C571 IDE rev 0x06: DMA, 
 channel 0 configured to compatibility, channel 1 configured to 
 compatibility
 wd0 at pciide0 channel 0 drive 0: WDC WD800BB-75JHC0
 wd0(pciide0:0:0): using PIO mode 4, DMA mode 2

 As you can see it's the same IDE chipset, same revision, same 
 drives.. the only thing I can think of is it's an IDE ribbon issue, 
 but the ribbons we used (which were mixed from the cases and the 
 motherboard boxes), were brand new.

 Any suggestions?

 TIA.