From smb94532543 at w-lan.mine.nu Mon May 1 01:51:54 2006 From: smb94532543 at w-lan.mine.nu (Niki Hammler) Date: Mon, 01 May 2006 03:51:54 +0200 Subject: "Guessing" superblock parameters Message-ID: <445569BA.20302@stiftingtal.net> Hi again, I have the following scenario: I've got a partition which has exactly 14659312 blocks: $ fdisk -l /dev/hda Disk /dev/hda: 28.5 GB, 28520497152 bytes 255 heads, 63 sectors/track, 3467 cylinders Units = Zylinder of 16065 * 512 = 8225280 bytes Ger?t Boot Start End Blocks Id System (...) /dev/hda4 1643 3467 14659312+ 83 Linux (...) Long, long time ago (5,6 years) I formatted this partition using a simple "mke2fs /dev/hda4" call. Block size is 4096. On 5th July, 2004, I accidently reformatted the partition with mke2fs -j /dev/hda4 without having a backup. Silly. (take a look at the '-j' switch which creates a journal!) After that, I spent weeks in reconstructing data and had partial success. I could reconstruct lots of mails, mysql tables, PHP documents and so on using self written scripts. The most important data. Even a 50MB gpg compressed file with finding indirect blocks. After that, I saved the image to disk, reformatted the partition and kept on working ;-) Last week, I searched for a file I've lost on that image. I just won't realize that my data is lost. It's still out there ;-) So I wrote a small program that finds all directory entries and had partial success: Most directory entries were found and in small directories with small files, the data in it followed the directory entry so that I could reconstruct whole directories. Now, I had the idea of searching for inodes. Maybe not all inodes are overwritten? What would you say? Are there chances that some inodes are not overwritten? Or are they all lost? Overwritten by zeros? Maybe not all of them are overwritten because of the '-j' switch? I modified the program "e2salvage" to find all inodes. I know, I had ~ 117807 files and directories on the disk. e2salvage found 85064 inodes. But I have the problem that on the disk there was an image (~1GB) with a whole Linux file system. I think block size also 4096. Do you think the inodes are from that image or could the inodes be from my data file system itself? And now the important question: Even if I would find a few inodes, they are useless, unless I know the addresses of the inode tables for each block group. Is there a way to reconstruct/guess the superblock parameters (block groups, inode tables, ...) if I have the the exact size of the partition and the block size (4096)? I also know that I've taken the default parameters for mke2fs. Is the filesystem (offset of inode tables, ...) the same everytime I format the same partition? If not, why? Thank you very much in advance! Niki From adilger at clusterfs.com Tue May 2 09:43:41 2006 From: adilger at clusterfs.com (Andreas Dilger) Date: Tue, 2 May 2006 03:43:41 -0600 Subject: "Guessing" superblock parameters In-Reply-To: <445569BA.20302@stiftingtal.net> References: <445569BA.20302@stiftingtal.net> Message-ID: <20060502094341.GE6075@schatzie.adilger.int> On May 01, 2006 03:51 +0200, Niki Hammler wrote: > And now the important question: Even if I would find a few inodes, they > are useless, unless I know the addresses of the inode tables for each > block group. > Is there a way to reconstruct/guess the superblock parameters (block > groups, inode tables, ...) if I have the the exact size of the partition > and the block size (4096)? I also know that I've taken the default > parameters for mke2fs. > > Is the filesystem (offset of inode tables, ...) the same everytime I > format the same partition? If not, why? Yes, this is generally true for a given blocksize. Even the journal is created after the inode tables are allocated. However, as part of the mke2fs the inode tables are zeroed, so this would in fact be bad in your case. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From s.steffann at computel.nl Tue May 2 10:58:34 2006 From: s.steffann at computel.nl (Sander Steffann) Date: Tue, 2 May 2006 12:58:34 +0200 Subject: "Guessing" superblock parameters In-Reply-To: <20060502094341.GE6075@schatzie.adilger.int> Message-ID: <2B1A983EDCEC3447B22632B64F72646014E993@bill.office.computel.nl> Hi, > > Is the filesystem (offset of inode tables, ...) the same everytime I > > format the same partition? If not, why? > > Yes, this is generally true for a given blocksize. Even the > journal is created after the inode tables are allocated. > However, as part of the mke2fs the inode tables are zeroed, > so this would in fact be bad in your case. You can use the -n option: -n causes mke2fs to not actually create a filesystem, but display what it would do if it were to create a filesystem. This can be used to determine the location of the backup superblocks for a particular filesystem, so long as the mke2fs parameters that were passed when the filesystem was originally created are used again. (With the -n option added, of course!) Good luck, Sander. From evilninja at gmx.net Wed May 3 06:29:15 2006 From: evilninja at gmx.net (Christian) Date: Wed, 3 May 2006 07:29:15 +0100 (BST) Subject: quota 101 In-Reply-To: References: <441C5926.20804@t-online.de> <441C595B.7070505@gmail.com> <54834.192.18.1.4.1143145387.squirrel@housecafe.dyndns.org> Message-ID: <62984.192.18.1.5.1146637755.squirrel@housecafe.dyndns.org> Hi list, having used ext2/3 for years now I have to admit that I've never dealt with filesystem quotas yet. But now I want to use them and I'm rather puzzled that I just can't get it working. I even consulted howtos... What I have done so far on this box (debian/i386, 2.6.17-rc3) - compiled in quota support: % zgrep -i quota /proc/config.gz # CONFIG_XFS_QUOTA is not set CONFIG_QUOTA=y CONFIG_QUOTACTL=y - touch /home/aquota.user; chmod 0600 /home/aquota.user - umount /home; edited fstab; mount /home % grep quota /proc/mounts /dev/sda6 /home ext3 rw,nosuid,nodev,noatime,data=ordered,usrquota 0 0 % quotacheck -av quotacheck: Scanning /dev/sda6 [/home] done quotacheck: Checked 4906 directories and 21239 files % edquota -F vfsv0 theo [...] % quotaon -auv -F vfsv0 quotaon: using /home/aquota.user on /dev/sda6 [/home]: No such process quotaon: Quota format not supported in kernel. ...running strace(1) on it: % strace quotaon -auv -F vfsv0 open("/home/aquota.user", O_RDONLY|O_LARGEFILE) = 3 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\21\37\300\331\0\0\0\0", 8) = 8 close(3) = 0 quotactl(Q_QUOTAON|USRQUOTA, "/dev/sda6", 2, {8169863311701010479, 7310315462216413045, 73014444146, 13253627510421192704, 1309965025280, 13253628303781025976, 0, 18446744069549162704}) = -1 ESRCH (No such process) write(2, "quotaon: ", 9quotaon: ) = 9 write(2, "using /home/aquota.user on /dev/"..., 62using /home/aquota.user on /dev/sda6 [/home]: No such process ) = 62 Can someone please explain to me what I am missing here? Also, why do I have to specify "-F vfsv0" all the time, isn't quotaV2 the default yet? What's even more irritating: my mount(8) manpage says for ext2: > grpquota / noquota / quota / usrquota > These options are accepted but ignored. (from: mount-2.12r) Thanks for your ideas, Christian. -- make bzImage, not war From nikolaus.hammler at telematik.edu Tue May 2 14:25:36 2006 From: nikolaus.hammler at telematik.edu (Nikolaus Hammler) Date: Tue, 02 May 2006 16:25:36 +0200 Subject: "Guessing" superblock parameters In-Reply-To: <2B1A983EDCEC3447B22632B64F72646014E993@bill.office.computel.nl> References: <2B1A983EDCEC3447B22632B64F72646014E993@bill.office.computel.nl> Message-ID: <44576BE0.2080209@telematik.edu> Sander Steffann schrieb: > Hi, > >>> Is the filesystem (offset of inode tables, ...) the same everytime I >>> format the same partition? If not, why? >> Yes, this is generally true for a given blocksize. Even the >> journal is created after the inode tables are allocated. >> However, as part of the mke2fs the inode tables are zeroed, >> so this would in fact be bad in your case. > > You can use the -n option: > > -n causes mke2fs to not actually create a filesystem, but > display > what it would do if it were to create a filesystem. This > can > be used to determine the location of the backup superblocks > for > a particular filesystem, so long as the mke2fs parameters > that > were passed when the filesystem was originally created are > used > again. (With the -n option added, of course!) Thank you for this information! I did it. But I found one strange thing: On a few block groups, there were at first the superblock and group descriptor (opt.) and then the two bitmaps. But after that, there was extactly one data block. In one such block e.g. there was an exe file. And AFTER this one data block the inodes followed (all zeroed out). In the data block bitmap the first byte was 0xff. Why that? I modified e2salvage again to save only the inodes that COULD be part of the inode table, i.e. the block had to be between block_group_beginning and block_group_beginning+inode_blocks+10. And I exactly found 2 inodes instead of 80000 :-( The two inodes are probably lost+found and the root directory of the reformatted file system. However, the the 80000 I've found before seem to belong to the file system images I had on that partition :-( So it's clear now: Continue playing puzzle :-( Thank you for your help! Niki From kernel-bugs at axxeo.de Wed May 3 12:54:56 2006 From: kernel-bugs at axxeo.de (Ingo Oeser) Date: Wed, 3 May 2006 14:54:56 +0200 Subject: We hit ext3_warning (inode->i_sb, "ext3_block_to_path", "block < 0"); Message-ID: <200605031454.56891.kernel-bugs@axxeo.de> Dear ext3-users, we hit this condition in fs/ext3/inode.c:ext3_block_to_path() if (i_block < 0) { ext3_warning (inode->i_sb, "ext3_block_to_path", "block < 0"); occasionally on two identical PATA-IDE disks copied over per filesystem-rsync. What is the impact of this condition? - Kernel was 2.6.13.4, CONFIG_LBD is not set but CONFIG_HIGHMEM4G=y (I can provide further details, if required) - S.M.A.R.T meant everything is ok on both disks. - Machine has been rebooted and fscked (180 days without reboot). - Result of this fsck is not known. The condition didn't happen after this anymore. Regards Ingo Oeser -- Ingo Oeser axxeo GmbH Tiestestr. 16, 30171 Hannover Tel. +49-511-4753706 Fax. +49-511-4753716 mailto:support at axxeo.de From evilninja at gmx.net Thu May 4 22:48:57 2006 From: evilninja at gmx.net (Christian) Date: Thu, 4 May 2006 23:48:57 +0100 (BST) Subject: quota 101 Message-ID: <38572.192.18.1.5.1146782937.squirrel@housecafe.dyndns.org> oh, I am using: $ quota -V Quota utilities version 3.13. Compiled with RPC and EXT2_DIRECT Bugs to mvw at planets.elm.net, jack at suse.cz are there any special versions out there for v2 quotas? thanks, Christian. ------------- Hi list, having used ext2/3 for years now I have to admit that I've never dealt with filesystem quotas yet. But now I want to use them and I'm rather puzzled that I just can't get it working. I even consulted howtos... What I have done so far on this box (debian/i386, 2.6.17-rc3) - compiled in quota support: % zgrep -i quota /proc/config.gz # CONFIG_XFS_QUOTA is not set CONFIG_QUOTA=y CONFIG_QUOTACTL=y - touch /home/aquota.user; chmod 0600 /home/aquota.user - umount /home; edited fstab; mount /home % grep quota /proc/mounts /dev/sda6 /home ext3 rw,nosuid,nodev,noatime,data=ordered,usrquota 0 0 % quotacheck -av quotacheck: Scanning /dev/sda6 [/home] done quotacheck: Checked 4906 directories and 21239 files quotacheck: Checked 4906 directories and 21239 files % edquota -F vfsv0 theo [...] % quotaon -auv -F vfsv0 quotaon: using /home/aquota.user on /dev/sda6 [/home]: No such process quotaon: Quota format not supported in kernel. ...running strace(1) on it: % strace quotaon -auv -F vfsv0 open("/home/aquota.user", O_RDONLY|O_LARGEFILE) = 3 _llseek(3, 0, [0], SEEK_SET) = 0 read(3, "\21\37\300\331\0\0\0\0", 8) = 8 close(3) = 0 quotactl(Q_QUOTAON|USRQUOTA, "/dev/sda6", 2, {8169863311701010479, 7310315462216413045, 73014444146, 13253627510421192704, 1309965025280, 13253628303781025976, 0, 18446744069549162704}) = -1 ESRCH (No such process) write(2, "quotaon: ", 9quotaon: ) = 9 write(2, "using /home/aquota.user on /dev/"..., 62using /home/aquota.user on /dev/sda6 [/home]: No such process ) = 62 Can someone please explain to me what I am missing here? Also, why do I have to specify "-F vfsv0" all the time, isn't quotaV2 the default yet? What's even more irritating: my mount(8) manpage says for ext2: > grpquota / noquota / quota / usrquota > These options are accepted but ignored. (from: mount-2.12r) Thanks for your ideas, Christian. -- BOFH excuse #1: clock speed From hahaha_30k at yahoo.com Sun May 7 08:25:07 2006 From: hahaha_30k at yahoo.com (Robinson Tiemuqinke) Date: Sun, 7 May 2006 01:25:07 -0700 (PDT) Subject: Fedora Core 4 and FC5's NEW EXT3 file system: "Reserved GDT blocks" ??? Message-ID: <20060507082507.75244.qmail@web36711.mail.mud.yahoo.com> Hi, I've installed a few Fedora Core 4 and Fedora Core 5 recently, and found that the new ext3 file systems created with new mkfs.ext3(1.38+) has one more field than EXT3 created with old mkfs.ext3(1.34-), even the latter's dir_index feature was turned on and file systems were upgraded with "e2fsck -y -f -D" command. I have three questions thereafter: 1) what does the "Reserved GDT blocks" mean? and what are its functions and purposes? 2) for file systems created with older versions of mkfs.ext3(v1.34-) on FC1, how to upgrade it to the newest version? I manually turned on dir_index(which is by default OFF for 1.34-, but by default ON on 1.38+) with command "tune2fs -O dir_index", then run command "e2fsck -y -f -D" to upgrade it (e2fsck is 1.38+). If the above upgrade way is the "official" way? If not, then what is the prefered way to upgrade old ext3 file system to be used on FC4/FC5? 3) are there any other difference besides "Reserved GDT blocks" between newly created ext3 file systems and upgraded ones by e2fsck? Please help. Thanks a lot. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tytso at mit.edu Mon May 8 02:33:46 2006 From: tytso at mit.edu (Theodore Tso) Date: Sun, 7 May 2006 22:33:46 -0400 Subject: Fedora Core 4 and FC5's NEW EXT3 file system: "Reserved GDT blocks" ??? In-Reply-To: <20060507082507.75244.qmail@web36711.mail.mud.yahoo.com> References: <20060507082507.75244.qmail@web36711.mail.mud.yahoo.com> Message-ID: <20060508023346.GB26076@thunk.org> On Sun, May 07, 2006 at 01:25:07AM -0700, Robinson Tiemuqinke wrote: > > I've installed a few Fedora Core 4 and Fedora Core 5 > recently, and found that the new ext3 file systems > created with new mkfs.ext3(1.38+) has one more field > than EXT3 created with old mkfs.ext3(1.34-), even the > latter's dir_index feature was turned on and file > systems were upgraded with "e2fsck -y -f -D" command. > > I have three questions thereafter: > > 1) what does the "Reserved GDT blocks" mean? and what > are its functions and purposes? It means that blocks have been reserved in order to allow on-line resizing. The filesystem will also have "resize_inode" in the filesystem features line reported by dumpe2fs. This is most useful if the filesystem has been created on a Logical Volume managed by an LVM system so that when the LV is expanded, the filesystem can take advantage of the new disk space without needing to unmount the filesystem first. Filesystems that don't have this set can of course still be resized off-line using resize2fs. > 2) for file systems created with older versions of > mkfs.ext3(v1.34-) on FC1, how to upgrade it to the > newest version? There isn't a way to do this that is supported by Fedora. You can use the ext2prepare tool that is part of ext2resize package on sf.net, but Red Hat hasn't been willing to support that package, and I haven't been willing to accept that code into the mainline e2fsprogs for code-quality reasons. (Doing a complete rewrite of the program from the ground up is on my todo list, but to be honest other things are higher priority.) > I manually turned on dir_index(which is by default OFF > for 1.34-, but by default ON on 1.38+) with command > "tune2fs -O dir_index", then run command "e2fsck -y -f > -D" to upgrade it (e2fsck is 1.38+). > > If the above upgrade way is the "official" way? If > not, then what is the prefered way to upgrade old ext3 > file system to be used on FC4/FC5? If you enable the dir_index field, when any directories grow beyond a single disk block, they are automatically become indexed using a hash tree. (There's no point using a hash tree if the directory is only a single block.) You can actually do this on a mounted filesystem, and it will take effect immediately. The "e2fsck -fD" command will cause e2fsck to rebuild and reindex any directories which are larger than a single disk block. So this will give you the benefit of directory indexing for all large directories on the filesystem. The directory indexing feature is completely orthogonal to the resize_inode feature (which allows on-line resizing). > 3) are there any other difference besides "Reserved > GDT blocks" between newly created ext3 file systems > and upgraded ones by e2fsck? Yes, see above. But unless your filesystem is on an LVM-managed LV, it probably doesn't matter so much that you can't on-line grow the filesystem. Hope this helps, - Ted From fk at linuxburg.de Wed May 10 10:35:36 2006 From: fk at linuxburg.de (Felix E. Klee) Date: Wed, 10 May 2006 12:35:36 +0200 Subject: Why different directory sizes? Message-ID: <200605101235.36848.fk@linuxburg.de> I just discovered two directories with the same number of files and the same number of hard links but different size: # stat /home/david/linuxburg/fax.old/docq_ps.nnnn \ /hdsync/home/david/linuxburg/fax.old/docq_ps.nnnn File: `/home/david/linuxburg/fax.old/docq_ps.nnnn' Size: 8192 Blocks: 16 IO Block: 4096 directory Device: 801h/2049d Inode: 52060 Links: 2 Access: (0775/drwxrwxr-x) Uid: ( 1000/ david) Gid: ( 100/ users) Access: 2006-01-30 04:15:15.000000000 +0100 Modify: 2006-01-16 19:33:28.000000000 +0100 Change: 2006-01-16 19:33:28.000000000 +0100 File: `/hdsync/home/david/linuxburg/fax.old/docq_ps.nnnn' Size: 16384 Blocks: 32 IO Block: 4096 directory Device: 811h/2065d Inode: 1128588 Links: 2 Access: (0775/drwxrwxr-x) Uid: ( 1000/ david) Gid: ( 100/ users) Access: 2006-03-11 16:45:25.000000000 +0100 Modify: 2006-01-16 19:33:28.000000000 +0100 Change: 2006-01-23 02:03:57.000000000 +0100 The file systems are identical, except that one is mounted "ro": # mount | grep -E '/hdsync/home |/home ' /dev/sda1 on /home type ext3 (rw,noatime,nodiratime,acl,user_xattr) /dev/sdb1 on /hdsync/home type ext3 (ro,noatime,nodiratime,acl,user_xattr) The kernel is a standard SuSE 9.2 one: # uname -a Linux pserver 2.6.8-24.14-default #1 Tue Mar 29 09:27:43 UTC 2005 i686 athlon i386 GNU/Linux What could be the reason for the different sizes? They confuse our backup script. -- Dipl.-Phys. Felix E. Klee Email: fk at linuxburg.de (work), felix.klee at inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15a, 76135 Karlsruhe, Germany From fk at linuxburg.de Wed May 10 10:40:45 2006 From: fk at linuxburg.de (Felix E. Klee) Date: Wed, 10 May 2006 12:40:45 +0200 Subject: Why different directory sizes? In-Reply-To: <200605101235.36848.fk@linuxburg.de> References: <200605101235.36848.fk@linuxburg.de> Message-ID: <200605101240.45616.fk@linuxburg.de> Forgot something, namely the number of files in each dir: # ls -l /hdsync/home/david/linuxburg/fax.old/docq_ps.nnnn | wc -l 209 # ls -l /home/david/linuxburg/fax.old/docq_ps.nnnn | wc -l 209 They're identical, as mentioned in my previous message. -- Dipl.-Phys. Felix E. Klee Email: fk at linuxburg.de (work), felix.klee at inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15a, 76135 Karlsruhe, Germany From tytso at mit.edu Wed May 10 11:17:26 2006 From: tytso at mit.edu (Theodore Tso) Date: Wed, 10 May 2006 07:17:26 -0400 Subject: Why different directory sizes? In-Reply-To: <200605101235.36848.fk@linuxburg.de> References: <200605101235.36848.fk@linuxburg.de> Message-ID: <20060510111726.GA29151@thunk.org> On Wed, May 10, 2006 at 12:35:36PM +0200, Felix E. Klee wrote: > I just discovered two directories with the same number of files and the same > number of hard links but different size: > > What could be the reason for the different sizes? They confuse our backup > script. The reason is history. Like many Unix filesystems, ext3 doesn't garbage collect empty blocks in a directory. So if you create a lot of files in a directory, and then delete them all, the directory doesn't shrink in size. In practice this isn't a problem, so we've never bothered to fix it. Why should your backup script care? It really shouldn't.... - Ted From fk at linuxburg.de Wed May 10 12:05:39 2006 From: fk at linuxburg.de (Felix E. Klee) Date: Wed, 10 May 2006 14:05:39 +0200 Subject: Why different directory sizes? In-Reply-To: <20060510111726.GA29151@thunk.org> References: <200605101235.36848.fk@linuxburg.de> <20060510111726.GA29151@thunk.org> Message-ID: <200605101405.39768.fk@linuxburg.de> On Wednesday 10 May 2006 13:17, you wrote: > Why should your backup script care? It really shouldn't.... It compares the size of the files on the original file system with those on the synchronized file system. So, if we leave out directories from that check, then we should be on the safe side, right? -- Dipl.-Phys. Felix E. Klee Email: fk at linuxburg.de (work), felix.klee at inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15a, 76135 Karlsruhe, Germany From menscher at uiuc.edu Wed May 10 15:22:05 2006 From: menscher at uiuc.edu (Damian Menscher) Date: Wed, 10 May 2006 10:22:05 -0500 (CDT) Subject: Why different directory sizes? In-Reply-To: <200605101405.39768.fk@linuxburg.de> References: <200605101235.36848.fk@linuxburg.de> <20060510111726.GA29151@thunk.org> <200605101405.39768.fk@linuxburg.de> Message-ID: On Wed, 10 May 2006, Felix E. Klee wrote: > On Wednesday 10 May 2006 13:17, you wrote: >> Why should your backup script care? It really shouldn't.... > > It compares the size of the files on the original file system with those on > the synchronized file system. So, if we leave out directories from that > check, then we should be on the safe side, right? Correct, but it sounds like you should be reading up on rsync or LVM snapshots to avoid reinventing the wheel. Damian Menscher -- -=#| www.uiuc.edu/~menscher/ Ofc:(650)253-2757 |#=- -=#| The above opinions are not necessarily those of my employers. |#=- From fk at linuxburg.de Thu May 11 09:50:48 2006 From: fk at linuxburg.de (Felix E. Klee) Date: Thu, 11 May 2006 11:50:48 +0200 Subject: Why different directory sizes? In-Reply-To: References: <200605101235.36848.fk@linuxburg.de> <200605101405.39768.fk@linuxburg.de> Message-ID: <200605111150.48760.fk@linuxburg.de> On Wednesday 10 May 2006 17:22, Damian Menscher wrote: > > It compares the size of the files on the original file system with those > > on the synchronized file system. So, if we leave out directories from > > that check, then we should be on the safe side, right? > > Correct, but it sounds like you should be reading up on rsync or LVM > snapshots to avoid reinventing the wheel. I'm all with you, but try telling that my boss. He prefers to only use the simplest tools and double check everything. Not necessarily a bad approach, but then one misses out many nice features of more powerful tools, for example incremental backups. Personally, I tend to bet on software such as "star" and "rsnapshot", and if I don't trust a tool, then I test it throughly. Automatic tests can be used to verify that backups still work properly after updates. But there's no time for that at my job ... -- Dipl.-Phys. Felix E. Klee Email: fk at linuxburg.de (work), felix.klee at inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15a, 76135 Karlsruhe, Germany From zab at zabbo.net Thu May 11 17:05:26 2006 From: zab at zabbo.net (Zach Brown) Date: Thu, 11 May 2006 10:05:26 -0700 Subject: Why different directory sizes? In-Reply-To: <200605111150.48760.fk@linuxburg.de> References: <200605101235.36848.fk@linuxburg.de> <200605101405.39768.fk@linuxburg.de> <200605111150.48760.fk@linuxburg.de> Message-ID: <44636ED6.1040305@zabbo.net> >> Correct, but it sounds like you should be reading up on rsync or LVM >> snapshots to avoid reinventing the wheel. Indeed, or: http://www.nongnu.org/rdiff-backup/ - z From fk at linuxburg.de Fri May 12 09:33:02 2006 From: fk at linuxburg.de (Felix E. Klee) Date: Fri, 12 May 2006 11:33:02 +0200 Subject: Why different directory sizes? In-Reply-To: <44636ED6.1040305@zabbo.net> References: <200605101235.36848.fk@linuxburg.de> <200605111150.48760.fk@linuxburg.de> <44636ED6.1040305@zabbo.net> Message-ID: <200605121133.02698.fk@linuxburg.de> On Thursday 11 May 2006 19:05, Zach Brown wrote: > Indeed, or: > > http://www.nongnu.org/rdiff-backup/ I know. In fact this looks like a very interesting alternative to "rsnapshot". I plan to install it at home some time, to make backups to a Buffalo LinkStation (and then perhaps from the LinkStation to some backup space on the Internet). -- Dipl.-Phys. Felix E. Klee Email: fk at linuxburg.de (work), felix.klee at inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15a, 76135 Karlsruhe, Germany From bimal_pandit at rediffmail.com Fri May 19 18:31:14 2006 From: bimal_pandit at rediffmail.com (bimal pandit) Date: 19 May 2006 18:31:14 -0000 Subject: [OT] Important Issue with "TIME" as we had with Y2K. Message-ID: <20060519183114.3000.qmail@webmail64.rediffmail.com> Dear User, In my previous article published in darpan 28/04/06 I mentioned ? technology is changing rapidly and there could be some unanticipated issues?, so here is the time to look into one... "Date" is one of the well known representation of "Time" and plays a critical role in our life. Just for an example our financial transactions, Important events, various schedules etc. all are directly related to "date/time", similarly it plays an important role in IT industry, our system uses date for various purposes e.g. various updates, application/program execution, backup schedules etc. etc. etc. and hence any variation, misrepresentation, error may lead to a great consequences. I hope you all remember Year 2000(Y2K) problem, just for ready reminder - in fact it was the way we represent "date" i.e. 05/05/75 is 5th May 1975, so date could be of maximum two digits(01-31), month could be of maximum two digits(01-12) but year needs to be four digits till "9999" and hence system could have gone haywire after the midnight of 31st December 1999 when the date was 01/01/00. This was what??? start of the first century or the twenty first century(1st January 2000)???, this misrepresentation and use had a great implications!!! but things were controlled soon with the change in this format, you all know that. But, why I am discussing all these??? OK, let me tell you another such an issue its "Year 2038 Problem", just go through this article which I have received long ago in a LINUX user group from Mr.Nitin Gupta, CEO, Xaprio Solutions. ------------ SNIP --------------- The Year 2038 Problem, Test it now... Disclaimer : This is just for FYI only. This is true and if you do this do at your own risk!!! 1. login to yahoo messenger(YM)/Gaim 2. send instant message to anyone - fine its working... 3. now, change your system date to 19-Jan-2038, 03:14:07 AM or above 4. Confirm weather your date is changed 5. again send instant message to anyone... Your YM/GAIM crashes ... * * YES ALL NETWORK BASED APPLICATION WILL NOT WORK NOW AND YOU MAY FACE ISSUES WITH OTHERS * * Why..., What is it? Starting at GMT 03:14:07, Tuesday, January 19, 2038, It is expected to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system interruptions, banking errors, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year 2038! Consider the year 2000 just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider that reports of temporal echoes of the 2038 problem are already starting to appear in future date calculations for mortgages and vital statistics! In the first month of the year 2038 C.E. many computers will encounter a date-related bug in their operating systems and/or in the applications they run. This can result in incorrect and wildly inaccurate dates being reported by the operating system and/or applications. The effect of this bug is hard to predict, because many applications are not prepared for the resulting "skip" in reported time anywhere from 1901 to a "broken record" repeat of the reported time at the second the bug occurs. Also, may make some small adjustment to the actual time the bug expresses itself. This bug to cause serious problems on many platforms, especially Unix and Unix-like platforms, because these systems will "run out of time". What causes it? Time_t is a data type used by C and C++ programs to represent dates and times internally. (Windows programmers out there might also recognize it as the basis for the CTime and CTimeSpan classes in MFC.) time_t is actually just an integer, a whole number, that counts the number of seconds since January 1, 1970 at 12:00 AM Greenwich Mean Time. A time_t value of 0 would be 12:00:00 AM (exactly midnight) 1-Jan-1970, a time_t value of 1 would be 12:00:01 AM (one second after midnight) 1-Jan-1970, etc.. some example times and their exact time_t representations: Date & time time_t representation 1-Jan-1970, 12:00:00 AM GMT 0 1-Jan-1970, 12:01:00 AM GMT 60 1-Jan-1970, 01:00:00 AM GMT 3 600 2-Jan-1970, 12:00:00 AM GMT 86 400 1-Jan-1971, 12:00:00 AM GMT 31 536 000 1-Jan-1972, 12:00:00 AM GMT 63 072 000 1-Jan-2038, 12:00:00 AM GMT 2 145 916 800 By the year 2038, the time_t representation for the current time will be over 2 140 000 000. And that's the problem. A modern 32-bit computer stores a "signed integer" data type, such as time_t, in 32 bits. The first of these bits is used for the positive/negative sign of the integer, while the remaining 31 bits are used to store the number itself. The highest number these 31 data bits can store works out to exactly 2 147 483 647. A time_t value of this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time. So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program will reach its upper limit. One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes. When a signed integer reaches its maximum value and then gets incremented, it wraps around to its lowest possible negative value. This means a 32-bit signed integer, such as a time_t, set to its maximum value of 2 147 483 647 and then incremented by 1, will become -2 147 483 648. Note that "-" sign at the beginning of this large number. A time_t value of -2 147 483 648 would represent December 13, 1901 at 8:45:52 PM GMT. So, if all goes normally, 19-January-2038 will suddenly become 13-December-1901 in every time_t across the globe, and every date calculation based on this figure will go haywire. And it gets worse. Most of the support functions that use the time_t data type cannot handle negative time_t values at all. They simply fail and return an error code. Solution "The best way to predict the future is to engineer it." Consider testing your mission-critical code well ahead of time on a non-production test platform set just before the critical date. For more general applications, just using large types for storing dates will do the trick in most cases. For example, in GNU C, 64-bits (a "long " type) is sufficient to keep the time from rolling over for literally geological eons This just means any executables the operating systems runs will always get the correct time reported to them when queried in the correct manner. It doesn't stop the executables you may still want to be worried about Well-written programs can simply be recompiled with a new version of the library that uses, for example, 8-byte values for the storage format. This is possible because the library encapsulates the whole time activity with its own time types and functions (unlike most mainframe programs, which did not standardize their date formats or calculations). So the Year 2038 problem should not be nearly as hard to fix as the Y2K problem was. Admittedly, some don't feel that this impending disaster will strike too many people. They reason that, by the time 2038 rolls around, most programs will be running on 64-bit or even 128-bit computers. In a 64-bit program, a time_t could represent any date and time in the future out to 292 000 000 000 A.D., which is about 20 times the currently estimated age of the universe. The problem with this kind of optimism is the same root problem behind most of the Year 2000 concerns that plagued the software industry in previous years: Legacy Code. Even if every PC in the year 2038 has a 64-bit CPU, there will be a lot of older 32-bit programs running on them. The greatest danger with the Year 2038 Problem is its invisibility. The more-famous Year 2000 is a big, round number; it only takes a few seconds of thought, even for a computer-illiterate person, to imagine what might happen when 1999 turns into 2000. But January 19, 2038 is not nearly as obvious. Software companies will probably not think of trying out a Year 2038 scenario before doomsday strikes. Of course, there will be some warning ahead of time. Scheduling software,billing programs, personal reminder calendars, and other such pieces of code that set dates in the near future will fail as soon as one of their target dates exceeds 19-Jan-2038, assuming a time_t is used to store them. ------------ SNIP --------------- OK, so by that time I don't know where we will be and what would be the technology, but the message is clear. In the last let Me ask you a very interesting question... could you tell me what was the day of the week on 3rd Sept. 1752 ? No!!!, OK, then have a choice and tell me for any of these 5th Sept. 1752, 9th Sept. 1752, 12th Sept. 1752. regards, Bimal Pandit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bimal_pandit at rediffmail.com Fri May 19 18:08:46 2006 From: bimal_pandit at rediffmail.com (bimal pandit) Date: 19 May 2006 18:08:46 -0000 Subject: [OT] Sendmail + LDAP HowTo. Message-ID: <20060519180846.1256.qmail@webmail67.rediffmail.com> Dear All, just to let people configure an email system, I have written an article on it and want that you should go through it, analyse and test it and help me to improve it further, while in case there is any error/mistake or correction is required please let me know. though I am not an expert but your valuable input will help me to understand the mailing system. SendMail + LDAP HowTo. http://fedoranews.org/cms/node/927 regards, Bimal Pandit -------------- next part -------------- An HTML attachment was scrubbed... URL: From julio at jmaranhao.com Mon May 22 00:40:21 2006 From: julio at jmaranhao.com (=?iso-8859-1?q?J=FAlio_Maranh=E3o?=) Date: Sun, 21 May 2006 21:40:21 -0300 Subject: How to learn about ext3? Message-ID: <200605212140.21463.julio@jmaranhao.com> Hi, I want to learn about ext3 fs from the basics to the inner details. Some hints about links that have that info well explained? Cheers. From kstrong at criminalinfo.net Tue May 23 17:20:14 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Tue, 23 May 2006 13:20:14 -0400 Subject: Monitoring FS operations Message-ID: <4473444E.1020801@criminalinfo.net> Greetings All, Without going into the specific reasons why I need to do so, is anyone aware of a method (or tool) of watching real-time, human-readable (or system call print) of ext3 filesystem operations on a mounted, active filesystem? Excuse me if this is a duplicate question but I was unable to find any similar ones in the archives. Thanks in advance! Kevin Strong Criminal Information Network From jp at enix.org Tue May 23 17:22:25 2006 From: jp at enix.org (=?ISO-8859-1?Q?J=E9r=F4me_Petazzoni?=) Date: Tue, 23 May 2006 19:22:25 +0200 Subject: Monitoring FS operations In-Reply-To: <4473444E.1020801@criminalinfo.net> References: <4473444E.1020801@criminalinfo.net> Message-ID: <447344D1.2040201@enix.org> > Without going into the specific reasons why I need to do so, is anyone > aware of a method (or tool) of watching real-time, human-readable (or > system call print) of ext3 filesystem operations on a mounted, active > filesystem? Look for the lm-profiler tool in the "laptop-mode" tools. It does (almost) that : modprobe(18534): dirtied inode 457921 (irda-utils) on sda2 modprobe(18534): dirtied inode 457920 (bluez) on sda2 modprobe(18534): dirtied inode 49330 (display_class) on sda2 modprobe(18534): dirtied inode 461377 (zaptel) on sda2 modprobe(18534): dirtied inode 58905 (blacklist) on sda2 modprobe(18534): dirtied inode 180040 (blacklist.d) on sda2 modprobe(18534): dirtied inode 1046702 (modules.dep) on sda2 dmesg(18537): dirtied inode 1030298 (dmesg_next) on sda2 dmesg(18572): dirtied inode 1030322 (dmesg_next) on sda2 dmesg(18597): dirtied inode 1030298 (dmesg_next) on sda2 dmesg(18624): dirtied inode 1030322 (dmesg_next) on sda2 modprobe(18650): dirtied inode 1046617 (modules.alias) on sda2 dmesg(18653): dirtied inode 1030298 (dmesg_next) on sda2 dmesg(18682): dirtied inode 1030322 (dmesg_next) on sda2 dmesg(18711): dirtied inode 1030298 (dmesg_next) on sda2 dmesg(18740): dirtied inode 1030322 (dmesg_next) on sda2 nmbd(4821): dirtied inode 572609 (browse.dat.) on sda2 nmbd(4821): dirtied inode 573668 (?) on sda2 pdflush(164): WRITE block 7177944 on sda2 pdflush(164): WRITE block 20070920 on sda2 pdflush(164): WRITE block 16035888 on sda2 pdflush(164): WRITE block 16035896 on sda2 lm-profiler(18769): dirtied inode 33606 (dmesg) on sda2 dmesg(18769): dirtied inode 964795 (locale-archive) on sda2 dmesg(18769): dirtied inode 1030298 (dmesg_next) on sda2 lm-profiler(18772): dirtied inode 360165 (diff) on sda2 That may or may not be what you want, however ! regards From kstrong at criminalinfo.net Tue May 23 17:48:27 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Tue, 23 May 2006 13:48:27 -0400 Subject: Monitoring FS operations In-Reply-To: <447344D1.2040201@enix.org> References: <4473444E.1020801@criminalinfo.net> <447344D1.2040201@enix.org> Message-ID: <44734AEB.10901@criminalinfo.net> J?r?me Petazzoni wrote: >>Without going into the specific reasons why I need to do so, is anyone >>aware of a method (or tool) of watching real-time, human-readable (or >>system call print) of ext3 filesystem operations on a mounted, active >>filesystem? > > > Look for the lm-profiler tool in the "laptop-mode" tools. It does > (almost) that : > > modprobe(18534): dirtied inode 457921 (irda-utils) on sda2 > modprobe(18534): dirtied inode 457920 (bluez) on sda2 > modprobe(18534): dirtied inode 49330 (display_class) on sda2 > modprobe(18534): dirtied inode 461377 (zaptel) on sda2 > modprobe(18534): dirtied inode 58905 (blacklist) on sda2 > modprobe(18534): dirtied inode 180040 (blacklist.d) on sda2 > modprobe(18534): dirtied inode 1046702 (modules.dep) on sda2 > dmesg(18537): dirtied inode 1030298 (dmesg_next) on sda2 > dmesg(18572): dirtied inode 1030322 (dmesg_next) on sda2 > dmesg(18597): dirtied inode 1030298 (dmesg_next) on sda2 > dmesg(18624): dirtied inode 1030322 (dmesg_next) on sda2 > modprobe(18650): dirtied inode 1046617 (modules.alias) on sda2 > dmesg(18653): dirtied inode 1030298 (dmesg_next) on sda2 > dmesg(18682): dirtied inode 1030322 (dmesg_next) on sda2 > dmesg(18711): dirtied inode 1030298 (dmesg_next) on sda2 > dmesg(18740): dirtied inode 1030322 (dmesg_next) on sda2 > nmbd(4821): dirtied inode 572609 (browse.dat.) on sda2 > nmbd(4821): dirtied inode 573668 (?) on sda2 > pdflush(164): WRITE block 7177944 on sda2 > pdflush(164): WRITE block 20070920 on sda2 > pdflush(164): WRITE block 16035888 on sda2 > pdflush(164): WRITE block 16035896 on sda2 > lm-profiler(18769): dirtied inode 33606 (dmesg) on sda2 > dmesg(18769): dirtied inode 964795 (locale-archive) on sda2 > dmesg(18769): dirtied inode 1030298 (dmesg_next) on sda2 > lm-profiler(18772): dirtied inode 360165 (diff) on sda2 > > That may or may not be what you want, however ! > > regards Thanks. That's a good start. Not what I was after but I'll see what it gives me on my box. I'm looking for something like "Filemon" from sysinternals.com (for Windows) - something that shows every operation sent to the FS driver. Thanks again. Kevin Strong Criminal Information Network From snitzer at gmail.com Tue May 23 19:16:08 2006 From: snitzer at gmail.com (Mike Snitzer) Date: Tue, 23 May 2006 15:16:08 -0400 Subject: Monitoring FS operations In-Reply-To: <44734AEB.10901@criminalinfo.net> References: <4473444E.1020801@criminalinfo.net> <447344D1.2040201@enix.org> <44734AEB.10901@criminalinfo.net> Message-ID: <170fa0d20605231216m75cda390w9e6dad4358dca619@mail.gmail.com> On 5/23/06, Kevin Strong wrote: > J?r?me Petazzoni wrote: > >>Without going into the specific reasons why I need to do so, is anyone > >>aware of a method (or tool) of watching real-time, human-readable (or > >>system call print) of ext3 filesystem operations on a mounted, active > >>filesystem? > > > > > > Look for the lm-profiler tool in the "laptop-mode" tools. It does > > (almost) that : > > > > modprobe(18534): dirtied inode 457921 (irda-utils) on sda2 > > modprobe(18534): dirtied inode 457920 (bluez) on sda2 > > modprobe(18534): dirtied inode 49330 (display_class) on sda2 > > modprobe(18534): dirtied inode 461377 (zaptel) on sda2 > > modprobe(18534): dirtied inode 58905 (blacklist) on sda2 > > modprobe(18534): dirtied inode 180040 (blacklist.d) on sda2 > > modprobe(18534): dirtied inode 1046702 (modules.dep) on sda2 > > dmesg(18537): dirtied inode 1030298 (dmesg_next) on sda2 > > dmesg(18572): dirtied inode 1030322 (dmesg_next) on sda2 > > dmesg(18597): dirtied inode 1030298 (dmesg_next) on sda2 > > dmesg(18624): dirtied inode 1030322 (dmesg_next) on sda2 > > modprobe(18650): dirtied inode 1046617 (modules.alias) on sda2 > > dmesg(18653): dirtied inode 1030298 (dmesg_next) on sda2 > > dmesg(18682): dirtied inode 1030322 (dmesg_next) on sda2 > > dmesg(18711): dirtied inode 1030298 (dmesg_next) on sda2 > > dmesg(18740): dirtied inode 1030322 (dmesg_next) on sda2 > > nmbd(4821): dirtied inode 572609 (browse.dat.) on sda2 > > nmbd(4821): dirtied inode 573668 (?) on sda2 > > pdflush(164): WRITE block 7177944 on sda2 > > pdflush(164): WRITE block 20070920 on sda2 > > pdflush(164): WRITE block 16035888 on sda2 > > pdflush(164): WRITE block 16035896 on sda2 > > lm-profiler(18769): dirtied inode 33606 (dmesg) on sda2 > > dmesg(18769): dirtied inode 964795 (locale-archive) on sda2 > > dmesg(18769): dirtied inode 1030298 (dmesg_next) on sda2 > > lm-profiler(18772): dirtied inode 360165 (diff) on sda2 > > > > That may or may not be what you want, however ! > > > > regards > > Thanks. That's a good start. Not what I was after but I'll see what it > gives me on my box. I'm looking for something like "Filemon" from > sysinternals.com (for Windows) - something that shows every operation > sent to the FS driver. There is also: http://loggedfs.sourceforge.net Mike From jburgess at uklinux.net Tue May 23 19:42:23 2006 From: jburgess at uklinux.net (Jon Burgess) Date: Tue, 23 May 2006 20:42:23 +0100 Subject: Monitoring FS operations In-Reply-To: <44734AEB.10901@criminalinfo.net> References: <4473444E.1020801@criminalinfo.net> <447344D1.2040201@enix.org> <44734AEB.10901@criminalinfo.net> Message-ID: <1148413344.22696.29.camel@shark.home> On Tue, 2006-05-23 at 13:48 -0400, Kevin Strong wrote: > J?r?me Petazzoni wrote: > >>Without going into the specific reasons why I need to do so, is anyone > >>aware of a method (or tool) of watching real-time, human-readable (or > >>system call print) of ext3 filesystem operations on a mounted, active > >>filesystem? > > > > > > Look for the lm-profiler tool in the "laptop-mode" tools. It does > > (almost) that : > > > > modprobe(18534): dirtied inode 457921 (irda-utils) on sda2 > > modprobe(18534): dirtied inode 457920 (bluez) on sda2 > > modprobe(18534): dirtied inode 49330 (display_class) on sda2 > > > > That may or may not be what you want, however ! > > > > regards > > Thanks. That's a good start. Not what I was after but I'll see what it > gives me on my box. I'm looking for something like "Filemon" from > sysinternals.com (for Windows) - something that shows every operation > sent to the FS driver. systemtap http://sourceware.org/systemtap/ could be used to monitor and report information from a selection of syscalls or ext3 specific APIs inside the kernel. Internally the kernel references the files by device+inode, not path name. To find a path to this inode you could monitor open() calls, but there may be multiple file paths which link to the same inode (e.g. hard links). It seems filemon has to do something similar on Windows to convert file handles back to file names, - How It Works ... "When FileMon sees an open, create or close call, it updates an internal hash table that serves as the mapping between internal file handles and file path names. Whenever it sees calls that are handle based, it looks up the handle in the hash table to obtain the full name for display. If a handle-based access references a file opened before FileMon started, FileMon will fail to find the mapping in its hash table and will simply present the handle's value instead." Jon From kstrong at criminalinfo.net Tue May 23 19:47:48 2006 From: kstrong at criminalinfo.net (Kevin Strong) Date: Tue, 23 May 2006 15:47:48 -0400 Subject: Monitoring FS operations In-Reply-To: <1148413344.22696.29.camel@shark.home> References: <4473444E.1020801@criminalinfo.net> <447344D1.2040201@enix.org> <44734AEB.10901@criminalinfo.net> <1148413344.22696.29.camel@shark.home> Message-ID: <447366E4.2070400@criminalinfo.net> Jon Burgess wrote: > On Tue, 2006-05-23 at 13:48 -0400, Kevin Strong wrote: > >>J?r?me Petazzoni wrote: >> >>>>Without going into the specific reasons why I need to do so, is anyone >>>>aware of a method (or tool) of watching real-time, human-readable (or >>>>system call print) of ext3 filesystem operations on a mounted, active >>>>filesystem? >>> >>> >>>Look for the lm-profiler tool in the "laptop-mode" tools. It does >>>(almost) that : >>> >>>modprobe(18534): dirtied inode 457921 (irda-utils) on sda2 >>>modprobe(18534): dirtied inode 457920 (bluez) on sda2 >>>modprobe(18534): dirtied inode 49330 (display_class) on sda2 >>> >>>That may or may not be what you want, however ! >>> >>>regards >> >>Thanks. That's a good start. Not what I was after but I'll see what it >>gives me on my box. I'm looking for something like "Filemon" from >>sysinternals.com (for Windows) - something that shows every operation >>sent to the FS driver. > > > systemtap http://sourceware.org/systemtap/ could be used to monitor and > report information from a selection of syscalls or ext3 specific APIs > inside the kernel. > > Internally the kernel references the files by device+inode, not path > name. To find a path to this inode you could monitor open() calls, but > there may be multiple file paths which link to the same inode (e.g. hard > links). It seems filemon has to do something similar on Windows to > convert file handles back to file names, > > - How It Works > ... > "When FileMon sees an open, create or close call, it updates an > internal hash table that serves as the mapping between internal file > handles and file path names. Whenever it sees calls that are handle > based, it looks up the handle in the hash table to obtain the full name > for display. If a handle-based access references a file opened before > FileMon started, FileMon will fail to find the mapping in its hash table > and will simply present the handle's value instead." > > Jon > > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users THAT is what I'm looking for. I'm assuming that there isn't anything that's more production-ready than that. Thank you! Kevin Strong Criminal Information Network From jburgess at uklinux.net Tue May 23 20:23:18 2006 From: jburgess at uklinux.net (Jon Burgess) Date: Tue, 23 May 2006 21:23:18 +0100 Subject: Monitoring FS operations In-Reply-To: <447366E4.2070400@criminalinfo.net> References: <4473444E.1020801@criminalinfo.net> <447344D1.2040201@enix.org> <44734AEB.10901@criminalinfo.net> <1148413344.22696.29.camel@shark.home> <447366E4.2070400@criminalinfo.net> Message-ID: <1148415798.22696.42.camel@shark.home> On Tue, 2006-05-23 at 15:47 -0400, Kevin Strong wrote: > THAT is what I'm looking for. I'm assuming that there isn't anything > that's more production-ready than that. > > Thank you! There are also some LSM based possibilities, although the LSM wasn't intended to be used for quite this task. SELinux could potentially give you an audit trail of what application did what and when via the audit messages. Unfortunately it does everything based on the file label and doesn't really care about the file path (it does log the device+inode though). Another possibility is AppArmour http://en.opensuse.org/AppArmor . I don't know if it is any more production ready or if it can be persuaded to do what you want. It enforces a file access policy for any given application based on file-path (so it must be tracking the file paths at open time). Jon From jca at sysgo.com Fri May 26 10:08:31 2006 From: jca at sysgo.com (Jan Capek) Date: Fri, 26 May 2006 12:08:31 +0200 (CEST) Subject: [PATCH - 2.6.17-rc5] ext3: Fix missed mutex unlock - unroll Message-ID: Hi, I believe the following patch in the GIT - 2.6.17-rc5 is not correct: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=75616cf9854b83eb83a968b1338ae0ee11c9673c It is the second of the two patches contributed by Leonid Ananiev. This one incorrectly adds the super block unlocking in the error path, though. As we can see in the function ext3_group_add() the unlock is already handled at the label 'exit_journal' for all error paths. Below is the patch that should be unrolled. Thanks, Jan Jan Capek SYSGO | Real-Time Solutions | ELinOS Embedded Linux | http://www.sysgo.com ---- From: Ananiev, Leonid I Date: Tue, 11 Apr 2006 05:54:38 +0000 (-0700) Subject: [PATCH] ext3: Fix missed mutex unlock X-Git-Tag: v2.6.17-rc2 X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=75616cf9854b83eb83a968b1338ae0ee11c9673c [PATCH] ext3: Fix missed mutex unlock Missed unlock_super()call is added in error condition code path. Signed-off-by: Leonid Ananiev Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- --- a/fs/ext3/resize.c +++ b/fs/ext3/resize.c @@ -767,6 +767,7 @@ int ext3_group_add(struct super_block *s if (input->group != sbi->s_groups_count) { ext3_warning(sb, __FUNCTION__, "multiple resizers run on filesystem!"); + unlock_super(sb); err = -EBUSY; goto exit_journal; } From mvolaski at aecom.yu.edu Sun May 28 22:39:21 2006 From: mvolaski at aecom.yu.edu (Maurice Volaski) Date: Sun, 28 May 2006 18:39:21 -0400 Subject: [Q] What would cause fsck running on a drbd device to just stop? Message-ID: drbd-0.7.19 under kernel 2.6.17-rc4 is running on a primary node standalone. There are 8 resources in the same group. fsck.ext3 -fv is being run simultaneously on all of them. Each of the drbd devices are running on an lv, which all belong to a single pv. The actual "disk" is a hardware RAID connected via SCSI (i.e., the mpt driver). Five of the fsck finished their tasks successfully and reported no problems. The remaining three got "stuck". There was no activity either on the physical RAID itself or listed in top. They were just listed as "D," uninterruptible sleep. Two of the fscks were at the end, giving the final summary information--no problems---for their respective filesystems and were stuck at that point. The last one was stuck in the first pass. Attempts to kill them failed; even kill -9 and attempting to shutdown were ignored. I rebooted manually and ran the three stuck ones again without a hitch. -- Maurice Volaski, mvolaski at aecom.yu.edu Computing Support, Rose F. Kennedy Center Albert Einstein College of Medicine of Yeshiva University From leonid.i.ananiev at intel.com Fri May 26 11:11:42 2006 From: leonid.i.ananiev at intel.com (Ananiev, Leonid I) Date: Fri, 26 May 2006 15:11:42 +0400 Subject: [PATCH - 2.6.17-rc5] ext3: Fix missed mutex unlock - unroll Message-ID: <6694B22B6436BC43B429958787E45498020A91EF@mssmsx402nb> Hi, Jan Capek writes > It is the second of the two patches contributed by Leonid Ananiev. I've sent one but not two patches according to "ext3: Fix missed mutex unlock". Here is my patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=114469290908779&w=2 --- fs/ext3/resize.c? 2006-04-06 01:08:28.367109040 -0700 +++ fs/ext3/resize.c?????? 2006-04-06 01:10:37.289509856 -0700 @@ -974,6 +974,7 @@ int ext3_group_extend(struct super_block ??????? if (o_blocks_count != le32_to_cpu(es->s_blocks_count)) { ??????????????? ext3_warning(sb, __FUNCTION__, ???????????? ????????????????"multiple resizers run on filesystem!"); +?????????????? unlock_super(sb); ??????????????? err = -EBUSY; ??????????????? goto exit_put; ??????? } This patch was applied to line 974 only but not to line 767 as described in attached mail. The patch for line 767 is contributed by Greg Kroah-Hartman and not signed by my as pointed in http://marc.theaimsgroup.com/?l=linux-kernel&m=114530988809825&w=2 Thanks, Leonid -----Original Message----- From: Jan Capek [mailto:jca at sysgo.com] Sent: Friday, May 26, 2006 2:09 PM To: sct at redhat.com; akpm at osdl.org; adilger at clusterfs.com Cc: ext3-users at redhat.com; Ananiev, Leonid I Subject: [PATCH - 2.6.17-rc5] ext3: Fix missed mutex unlock - unroll Hi, I believe the following patch in the GIT - 2.6.17-rc5 is not correct: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=75616cf9854b83eb83a968b1338ae0ee11c9673c It is the second of the two patches contributed by Leonid Ananiev. This one incorrectly adds the super block unlocking in the error path, though. As we can see in the function ext3_group_add() the unlock is already handled at the label 'exit_journal' for all error paths. Below is the patch that should be unrolled. Thanks, Jan Jan Capek SYSGO | Real-Time Solutions | ELinOS Embedded Linux | http://www.sysgo.com ---- From: Ananiev, Leonid I Date: Tue, 11 Apr 2006 05:54:38 +0000 (-0700) Subject: [PATCH] ext3: Fix missed mutex unlock X-Git-Tag: v2.6.17-rc2 X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=75616cf9854b83eb83a968b1338ae0ee11c9673c [PATCH] ext3: Fix missed mutex unlock Missed unlock_super()call is added in error condition code path. Signed-off-by: Leonid Ananiev Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- --- a/fs/ext3/resize.c +++ b/fs/ext3/resize.c @@ -767,6 +767,7 @@ int ext3_group_add(struct super_block *s if (input->group != sbi->s_groups_count) { ext3_warning(sb, __FUNCTION__, "multiple resizers run on filesystem!"); + unlock_super(sb); err = -EBUSY; goto exit_journal; }