similar to: sparse loop devices and ext3

Hi Stephen, We had some starvation/locks happening to us under very heavy load in two cases: - InterMezzo asked ext3 to do a journaled file write (for 1 block) essentially using ext3_write - similarly for truncate. These lockups went away when we started the transaction in InterMezzo and reserved somewhat more space than ext3 does. Any clues as to what this might be? Are the ext3

[ If this is explained somewhere else (HOWTO or FAQ), please give me a pointer. ] Is there any way to mix loop-device (and in particular) loop-AES and ext3 together in data journaling mode? Ie. bottom -> to -> top ext3 - loop-AES - ext3 raw - loop-AES - ext3 Or am I shooting myself to leg, I am? BR, Jani -- Jani Averbach

Hi, We hit an interesting issue with Ext3 in ordered data mode. A large file was truncated (open with O_TRUNC) and immediately over-written with a single write call. The write call returned ENOSPACE, but a check for space (using essentially statfs) promised that there would be plenty of space. The reason turned out to be that the blocks freed by the truncation were not yet available to the

Signed-off-by: Alexey Dobriyan <adobriyan at mail.ru> --- fs/ext3/resize.c | 20 ++++++++++---------- fs/ext3/super.c | 8 ++++---- include/linux/ext3_fs.h | 2 +- 3 files changed, 15 insertions(+), 15 deletions(-) Index: linux-warnings/include/linux/ext3_fs.h =================================================================== ---

An ext3 update for Alan's latest kernel is at http://www.uow.edu.au/~andrewm/linux/ext3/ The version of ext3 in -ac kernels currently stands at 0.9.6, so this is a fairly large diff. However most of this code has had a decent amount of external testing via the 0.9.9 patch. The changelog since 0.9.6 is below. Please test it if you can, and all being well we shall ask Alan to merge it a

Given that the default journaling mode of ext3 (i.e. ordered), does not guarantee write ordering after a crash, is this journaling mode safe enough to use for a database such as Oracle? If so, how are out of sync writes delt with? Kind regards, Herta Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

I'm writing a stackable file system and one of it's features is that it can combine many sparse files into a single view. On ext2/3 I was using bmap to give me the information needed, so for instance, if I created a big sparse file and tacked on some information at the end on ext2/3 I'd get something like blade12:~# ~/a.out abc File: abc Size: 30002 Blocks: 8 Blocksize: 4096 0

Can anybody tell me if quota information is journaled ? After bad-shutdown the quota info is correctly or I need run quotacheck ?

hi, is this rpms differ from redhat's rawhide 2.4.5 kernel which seems to contain ext3. so my question that your rpm contain different ext3 than rh's rpm? or I can simple use rh's rawhide rpms? thanks. yours. ps. please reply to my private address to since I'm not on the list. thanks. > Hi, > > Mostly for my own use, I prepared two kernel RPM's with Ext3 in them.

Hello. I'm having serious issues with ext3; any insight would be greatly appreciated: _____ Overview: I believe ext3 is supposed to be recoverable in the case of a power failure by replaying the log. However, on two separate computers (running different operatings systems too), this has been everything but the case. _____ Specifics: Sometimes, my kernel will hard-freeze and I'll

Hello, Many warm thank yous to Bill Rugolsky Jr. and Stephen Tweedie for their help on this one. Both pointed out that since the file system is journaled, if the primary box (nas1) were to crash, the secondary box should mount the ext3 file system without any problems. Depending on the nature of the journal (metadata journaling and/or data journaling), we may have little or no data loss. Bill

hi i got 2 questions and maybe someone could shed some light: a) i'm using kernel 2.4.17 and use ext3 in it. is it possible that the whole system is slower than with ext2? i switched back to ext2 (great feature!!!) and the system's response seemed somewhat better. should/could there be such a effect as double writing of journaled data? i didnt activate debugging (jbd). b) is reiserfs

Hi, I have a detailed question about ordered data writes. Suppose we (i.e. intermezzo) does a transaction, which is closed and then followed by an ordered write. Let's assume the ordered write doesn't require new allocation metadata. Is the write still postponed until the first transaction has committed? As far as I can see, prepare_write always starts a transaction, but I'm

My application always needs to sync file data after writing. I don't want anything handing around in the kernel buffers. I am wondering what is the best method to accomplish this. 1. Do I use EXT2 and use fdatasync() or fsync()? 2. Do I use EXT2 and mount with the "sync" option? 3. Do I use EXT2 and use the O_DIRECT flag on open()? 4. Do I use EXT3 in full journaled mode,

Hi, I've been wondering exactly what you gain by using journaled mode over ordered mode. Are there any known cases where journaled mode could recover where ordered mode wouldn't? Mike

Hi ext3 users: Here I have a problem with how sync works on ext3. Basically I am using ext3 and GRUB on flash. What happens is: 1. ftp two big boot images into ext3 (on a flash) 2. do sync 3. reset immediately (without umounting) 4. GRUB cannot find the two images 5. boot with another image, and the two images are there (b/c journal was replayed) ext2 doesnt have this problem. My first

Hi! Are these results i got from my benchmarking "normal" or is there something strange happening in my system? This box is going to be a mailserver, so i tested various fs to decide on which i should utilize. I personally dislike reiserfs because it has proven somehow unreliable on our servers (although it got better in the more recent kernels), ext3 would be quite good (fsck'ing

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

It seems to me that it should be possible to make --inplace and --sparse compatible. The manpage says -S, --sparse ... Conflicts with --inplace because it's not possible to overwrite data in a sparse fashion. but I think it _is_ possible to do that, provided the receiving side opens the dest file read-write instead of write-only. When writing within the existing

Is there a way to find the holes in sparse files, other than assuming contiguous blocks of zeroes are holes? Thanks, Sean