jeffl@comix.UUCP (Jeff Liebermann) (06/25/91)
How does one deal with a bogus 1Gigabyte file? I have a Xenix 2.3.3 system that has ls magically declare a 45Mb accounting file as 1Gbyte huge. ls declares it to be 1Gb big. du agrees. df -v gives the correct filesystem size. fsck "Possible wrong file size I=140" (no other errors). To add to the problem, I'm having difficulty doing a backup before attacking. compress bombs due to lack of working diskspace. tar, cpio, afio insist on trying to backup 1Gb of something. dd at least works and I can fit the 130Mb filesystem on one QIC-150 tape (whew). To add to the wierdness, all the reports generated by the application (Armor Systems Excalibur Acctg) work perfectly as if nothing were wrong. Obviously a job for fsdb. However, every book I own and the SCO ADM manuals give a terse and/or trivial example of fsdb usage. Can anyone recommend a book that has a detailed explanation for using fsdb? Any brilliant advice? -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # 408.336.2558 voice WB6SSY @ KI6EH.#NOCAL.CA.USA packet radio # 408.699.0483 digital pager 73557,2074 cis # jeffl@comix.santa-cruz.ca.us uunet!comix!jeffl jeffl%comix@ucscc.ucsc.edu
aab@cichlid.com (Andy Burgess) (06/25/91)
In article <124@comix.UUCP> jeffl@comix.Santa-Cruz.CA.US (Jeff Liebermann) writes: >How does one deal with a bogus 1Gigabyte file? >I have a Xenix 2.3.3 system that has ls magically >declare a 45Mb accounting file as 1Gbyte huge. > >ls declares it to be 1Gb big. >du agrees. >df -v gives the correct filesystem size. >fsck "Possible wrong file size I=140" (no other errors). > >To add to the problem, I'm having difficulty doing >a backup before attacking. > >compress bombs due to lack of working diskspace. >tar, cpio, afio insist on trying to backup 1Gb of something. >dd at least works and I can fit the 130Mb filesystem on one >QIC-150 tape (whew). To add to the wierdness, all the >reports generated by the application (Armor Systems Excalibur >Acctg) work perfectly as if nothing were wrong. > Could be a sparse file. I'm not sure if Xenix supports sparse files but on modern unices you can open a file, seek a billion bytes or so into it and write one byte. Only one sector of data is allocated (plus some inode sectors). Reading the file returns zeros for the unwritten sectors. ls reports the offset of the last byte in the file. Tar, cpio et al traditionally do not detect sparse files and merrily save a gigabyte of zeros (although I would have expected compress to work eventually). >Obviously a job for fsdb... I don't think you have anything to fix. Well maybe a bug in the application that created the file. Don't know about the fsck message though... Andy -- Andy Burgess Independent Software Consultant and Developer aab@cichlid.com uunet!silma!cichlid!aab
md@sco.COM (Michael Davidson) (06/26/91)
jeffl@comix.UUCP (Jeff Liebermann) writes: >How does one deal with a bogus 1Gigabyte file? >I have a Xenix 2.3.3 system that has ls magically >declare a 45Mb accounting file as 1Gbyte huge. >ls declares it to be 1Gb big. >du agrees. >df -v gives the correct filesystem size. >fsck "Possible wrong file size I=140" (no other errors). >To add to the problem, I'm having difficulty doing >a backup before attacking. >compress bombs due to lack of working diskspace. >tar, cpio, afio insist on trying to backup 1Gb of something. >dd at least works and I can fit the 130Mb filesystem on one >QIC-150 tape (whew). To add to the wierdness, all the >reports generated by the application (Armor Systems Excalibur >Acctg) work perfectly as if nothing were wrong. It is possible that the application generated a "sparse" file by seeking to a 1Gbyte offset and writing some data. If this is really the case then it is very unfriendly behaviour on the part of the application (for all of the reasons you outlined above). >Obviously a job for fsdb. However, every book I own and >the SCO ADM manuals give a terse and/or trivial example of >fsdb usage. Can anyone recommend a book that has a detailed >explanation for using fsdb? Any brilliant advice? Actually I think that all you need here is "rm". If you know what size the file *should* be (assuming that the 1Gbyte size is in fact an error and not something that the application did deliberately) and you care about the current contents of the file you can just use dd to copy the appropriate amount of data from the 1Gbyte file to a temporary file, remove the offending file and move the temporary file back to whatever name the accounting file should have. You might want to run fsck afterwards just for luck, but since your previous fsck run only reported a possible file size error there should be no problems (ie you didn't have any "duplicate block" or "bad block" errors did you?) If you don't care about the current contents of the file just remove it. I'm afraid that there isn't any really good documentation on fsdb that I know of .....
rogerk@sco.COM (Roger Knopf 5502) (06/26/91)
In article <124@comix.UUCP> jeffl@comix.Santa-Cruz.CA.US (Jeff Liebermann) writes: >How does one deal with a bogus 1Gigabyte file? >I have a Xenix 2.3.3 system that has ls magically >declare a 45Mb accounting file as 1Gbyte huge. > >ls declares it to be 1Gb big. >du agrees. >df -v gives the correct filesystem size. >fsck "Possible wrong file size I=140" (no other errors). > >To add to the problem, I'm having difficulty doing >a backup before attacking. It may not be anything "wrong" with the inode. There may just be a gap where nothing was written. For example, if you do an lseek of 10,240 and write 1K the utilities above will show the file size to be 11K when in reality you have used only one block. dbm did this at one time (don't know about now). The real problem lies in that no utility recognizes these intervening empty blocks as not actually there. After all, if you read back the above file, you will get 10K of nulls and then your data. So if you use cp, tar, cpio, etc. they "fill in the blanks" and make your file actually be the logical size by writing nulls in all the empty blocks. There are two ways of dealing with this problem: 1) Most databases have a utility which dumps records and loads them. Use this to back up the data. To restore the data you make empty data files and use the load utility. This is the preferred method if available. It also has the side benefit of (usually) making the new files run faster. 2) This is ugly but effective. It only works assuming the "sparse" file scenario. Use the attached program to compress it. To read it back, read in each struct, lseek to the offset in lseekval and then write the block (actually n bytes) to the output file. -------------------------- sparsecp.c --------------------------- #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #define BSIZE 1024 struct orec { long lseekval; int cnt; unsigned char buf[BSIZE]; } rec; main(argc, argv) int argc; char *argv[]; { int infd, outfd, n; long offset; /* error checking is left as an excersize for the reader */ infd=open(argv[1], O_RDONLY); outfd=creat(argv[2], 0700); offset=0; while ((n=read(infd, rec.buf, BSIZE)) > 0) { if (notempty(rec.buf)) { rec.lseekval=offset; rec.cnt=n; write(outfd, &rec, sizeof (struct orec)); nullout(rec.buf); if (n != BSIZE) /* partial block at EOF */ break; } offset+=BSIZE; } close(infd); close(outfd); } notempty(s) unsigned char s[]; { register i; for (i=0; i<BSIZE; ++i) if (s[i]) return(1); return(0); } nullout(s) char s[]; { register i; for (i=0; i<BSIZE; ++i) s[i]='\0'; } ---------------------------------- end ------------------------------ -- Roger Knopf "Oh my...." SCO Consulting Services -- Our Pal, Marty Stevens uunet!sco!rogerk or rogerk@sco.com 408-425-7222 (voice) 408-458-4227 (fax)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/27/91)
There's nothing wrong with your file. It's a sparse file, with a random write done at offset 1GB. You can back it up with dump. You can delete it with rm. You can muck up your files beyond any recovery with fsdb. Repeat: there's nothing wrong, yet. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) GE Corp R&D Center, Information Systems Operation, tech support group Moderator comp.binaries.ibm.pc and 386-users digest.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/27/91)
In article <1991Jun25.064730.11188@cichlid.com> aab@cichlid.com (Andy Burgess) writes: | I don't think you have anything to fix. Well maybe a bug in the application | that created the file. Don't know about the fsck message though... The message comes out for all sparse files. Many coredumps are sparse. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) GE Corp R&D Center, Information Systems Operation, tech support group Moderator comp.binaries.ibm.pc and 386-users digest.