search for: thiesen

On Thu, Oct 16, 2014 at 11:01:35PM +0200, Bodo Thiesen wrote: > > Since it never get's updated unless the file system is unmounted, it can > only be used for a 24 hours test by mounting the file system now, > unmounting it 24 hours from now and then taking the difference. It also gets updated if the file system syncfs(2) or sync(2) sy...

----- Original Message ----- From: "Bodo Thiesen" <bothie@gmx.de> To: <ext3-users@redhat.com> Sent: Monday, August 25, 2014 8:15 PM Subject: Re: filesystem > Hello Bill. [snip] > You're trying to understand what exactly? From the user point of view, > dir_index just makes directory accesses on very big directories f...

* Andreas Dilger <adilger@dilger.ca> hat geschrieben: > The "lifetime writes" value has not been around forever, so if the > filesystem was originally created and populated on an older kernel > (e.g. using ext3) it would not contain a record of those writes. It was created as stable ext4 in the first place. So only if there was a stable ext4 release which didn't

* Keith Keller <kkeller@wombat.san-francisco.ca.us> hat geschrieben: Hi Keith > I have a very similar second server which has undergone a similar chain > of events, an initial ~2.5tb fs followed by a resize later. I believe > that it has been fsck'd since the resize (but don't quote me on that). > Am I likely to run into this issue with this fs? And if I do, what >

Hi all, On Mon, Jun 02, 2014 at 11:04:52PM +0200, Bodo Thiesen wrote: > > Keith is not the first one with problems of this class and he will > probably not be the last one. He later told us, that at first, mounting > the file system still worked. Is there any value in discussing this issue in keeping this broken filesystem available for debugging...

Hello Bill again. Two things. First. I read this mailing list, so no need to send answers to me personally in copy. Second. I guessed it already, but now it got really obvious, that you didn't do your homework. Please search for your questions in your favorite search engine first. Yes, I know, that there is not much easy to understand information on ext2 (in all flavours) out there, but

On Oct 16, 2014, at 10:25 AM, Bodo Thiesen <bothie@gmx.de> wrote: > * Andreas Dilger <adilger@dilger.ca> hat geschrieben: > >> You can see in the ext4 superblock the amount of data that has been >> written to a filesystem over its lifetime: >> >> Note that this number isn't wholly accurate, bu...

* "Theodore Ts'o" <tytso@mit.edu> hat geschrieben: Hi Theodore. > That being said, it's pretty clear that portions of the inode table > and block group descriptor was badly corrupted. [...] Keith is not the first one with problems of this class and he will probably not be the last one. He later told us, that at first, mounting the file system still worked. And that

* Andreas Dilger <adilger@dilger.ca> hat geschrieben: > You can see in the ext4 superblock the amount of data that has been > written to a filesystem over its lifetime: > > Note that this number isn't wholly accurate, but rather a guideline. Is is more like a completely bogus value at best: # LANG=C df -h / | grep root /dev/root 3.7T 3.6T 73G 99% / # grep [0-9]

Hello ext users, in a recurrent need to be able to traverse large filesystems (10-350M inodes) backed by spindle-based RAID arrays, I tried several solutions (like intercepting readdir and sorting by inode, playing with cache hints, and such), to no avail. Since I'm mostly facing ext3 and ext4 filesystems, I wrote a tool based on libe2fs which replaces the 'find /' part by

* "Bill Cunningham" <billcun@suddenlink.net> hat geschrieben: > I hope this is the right list. I have created an ext2 filesystem and > removed the dir_index feature. I don't know if this kind of experimentation > is going to help me learn something about filesystems or not. Well what is > dir_index? Then I ran e2fsck -f -v -pD and the /dev file. Now what did I >

Dear All, I have a following query: - My initrd image is created using ext2 filesystem. - The filesystem type of / is specified as ext3 in /etc/fstab file. - I dont mount the real root during execution of linuxrc because I referred some documents saying that if you dont mount real root from linuxrc the kernel will mount it after linuxrc is finished. - The system boots up successfully, mount

...ver for UNIX ollik:root # uname -a FreeBSD ollik 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #2: Fri Feb 25 19:00:04 CET 2005 root@ollikn:/usr/obj/usr/src/sys/MOD64 amd64 Thanks in advance for your help. Bye, K&K, T-Zee -- thiesi@NetWorkXXIII.de - http://Hausmeister.Maedchenpension.at/ Mirko Thiesen - Soemmeringstrasse 41 - D-10589 Berlin - Germany Fax: +49 30 34389203 - NetBSD: Powering your servers since 1993 "We're with you all the way, mostly"

I hope this is the right list. I have created an ext2 filesystem and removed the dir_index feature. I don't know if this kind of experimentation is going to help me learn something about filesystems or not. Well what is dir_index? Then I ran e2fsck -f -v -pD and the /dev file. Now what did I remove? Htree. I guess it can always be put back and it's on an experimental filesystem.

Having just spent a day trying to recover a deleted ext3 file for a friend, I'm wondering about this way of maintining undelete information in ext3, like is done for ext2: The last step in the deletion process would be to put back the (previously zeroed) block pointers. Since it gets logged to the journal, I _think_ that this should be safe. The worst that would happen is that, if the plug

High, i tried to install the free Visual Pinball package from: http://www.randydavis.com/vp/intro.htm When i tried to run the installer it aborted with an error message to check the installer package. Whe i try to run the VPinball.exe directly without using the installer it comes up well. But now when i try to load a table i get the error that modul RichEdit32A Module is missing. peter

Hello. After reading some mails from mailing list archives and other sources, ext3 seems to having troubles in deleting files w/o destroying the data neccessary to undelete them. Ok, I know what journaling means, and in any way, the ext3 fs driver needs to keep track of which blocks have actually been marked as being free. But now my question: Who say, that this information must be stored in