search for: blockcounts

Greetings all- I am conducting security testing on a device that uses Linux 2.4 with ext3. I am testing secure overwrite of remnant data in temporary files, but have run into a real good stumpper in the way Ext allocates data blocks. I've got 10 yrs of *NIX behind me, several with Linux, and this has really got me perplexed as I can't find any documentation explaining the subject

Over the last two days we've been seeing a fair bit of this: ---- # ls -laR > /dev/null ... ls: ./server2/b/user/bxyz/392.: Input/output error ---- This is with the latest htree patches applied to 2.4.19, and latest e2fsprogs-test, on a dual AMD system, with 5x73GB SCSI drives on a MegaRAID controller. We're using the gcc 2.96 that comes with RH7.3. esfsck shows "Inodes that

Hi, all, I "found" a big bug either related with Linux Ext3 file system or "bin/ls" command. The problem is: File system is no more than 220GB, but "/bin/ls" reports holding >370GB data! The system is Redhat 8.0, with a Generic Kernel 2.4.20. Any suggestions are greately appreciated. more information can be available upon requests. The following is the

I have a disk where serveral files have a file size that is much bigger then the space they actually use. THe file size is bogus. In the example below, the size is reported as 4.2MB but the file is really supposed to be on 116K which is true accoring to du and the block list from debugfs. However, doing a 'cat |wc' file actually gives me 4.2MB bytes. Where are those extra bytes coming

Hi, I've run many time e2fsck, but in a special dir ls tells me: ls: r?cksendung-wlan.dvi: No such file or directory ls: baf?g_r?ckmeldung.latex: No such file or directory ls: finpr?f.pdf: No such file or directory $ cat finpr?f.pdf cat: finpr?f.pdf: Datei oder Verzeichnis nicht gefunden I don't know what to do? How can I find the failure? If I cat the files with debugfs, I see the

Dear centos community, I was in the process of loading the latest 5.5 release of centos in a VMWARE ESX 4.1 host as my first virtual machine, suddenly while booting I got a panic error with the following on screen. Can someone point me in the right direction. This machine has 24 cores and I allocated 1 for Centos to use with 1024MB of memory. Any clues or workaround to solve this problem? Thank

Hi, There is any way to figure out where physically is the journal on a ext3 fs and it's size? Thanks! Jordi

Hi John!! >1) Have you ensured that your passes have different arguments to the = >RegisterPass constructor (i.e., they have different names)? Yes, I only write one Pass (Function Pass) and gave it that one name. >2) Are you sure that variable X is only being defined once? There are = >some ways in which you could have unintentionally defined it twice. For = >example, if you

I made the mistake of looking at disk IO numbers in two different ways -- now I'm confused, because they give inconsistent answers. First way was using 'vmstat 10'. This gave me (apologies for wrapped lines): r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 2162944 4071928 162444 4218456 0 0 0 286 1103 528 3 2 95 0 0 1 0

Hi list, here's what just happend: I rebooted my 2.4.15 running machine with SysRq + s u b to boot into 2.4.17pre8. All went fine, fsck found no errors. Upon starting X i found out that my .opera directory went fubar in some way. Stracing ls shows that it gets an EIO trying to stat it. Looking at it with debugfs (and learning fs internals on the fly) shows that inode of that directory only

...w many times the function was entered. (This is especially necessary > + // if there is only the entry block.) > + std::map<Function*, EdgeCounts> EdgeInformation; > + > + // BlockInformation - Count the number of times a block is executed > + std::map<Function*, BlockCounts> BlockInformation; > + > + // FunctionInformation - Count the number of times a function is executed > + std::map<Function*, double> FunctionInformation; Instead of multiple maps from Function* ->, would it make sense to collect these three (or four) maps inside a per-fu...

Hello, I've got a problem that is not solved after an e2fsck. What happens is that the kernel (vanilla 2.6.12) does this: journal_bmap: journal block not found at offset 1036 on hda6 Aborting journal on device hda6. ext3_abort called. The filesystem is mounted with errors=panic, so the system reboots. At boot-up an e2fsck is run on /dev/hda6. Sometimes it finds errors, sometimes not.

Hi, I'm trying to understand if my journal is fragmented. Here's some output from `debugfs -R "stat <8>" /dev/sda3`: Inode: 8 Type: regular Mode: 0600 Flags: 0x0 Generation: 0 User: 0 Group: 0 Size: 104857600 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 205016 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x3c0442fd -- Tue Nov 27

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

Hello, I have 2 boxes with 1.5TB storage with ext3 fs, and the kernel is 2.6.11.8. I'm using E2fsprogs 1.37 for FS creation. And, Filesystem revision #: 1 (dynamic) There are 2 scenarios: 1. All SATA drives, RAID5 2. All PATA drives, RAID5 and wrapped in log volumes. I'm having lots of issues with fsck. I did search, but somehow not getting the right information. needs_recovery

...ction was entered. (This is especially necessary >> + // if there is only the entry block.) >> + std::map<Function*, EdgeCounts> EdgeInformation; >> + >> + // BlockInformation - Count the number of times a block is executed >> + std::map<Function*, BlockCounts> BlockInformation; >> + >> + // FunctionInformation - Count the number of times a function is executed >> + std::map<Function*, double> FunctionInformation; > > Instead of multiple maps from Function* ->, would it make sense to collect these > three (or...

This pull request contains the XFS filesystem driver for Syslinux. Due to historical reasons (SGI IRIX's design of disk layouts), the first sector in the primary AG on XFS filesystems contains the superblock, which is a problem with BIOSes, since VBRs must be loaded up from the first sector of the active partition. Thus, we needed to handle this issue by putting the Syslinux bootsector