similar to: ext3-0.0.6a available

Hi all, OK, here is ext3-0.0.5e. Changes since 5d are summarised below. The major changes are the barrier support: this infrastructure should be sufficient to allow the snapshotting interface which LVM is wanting for ext3. The journal initialisation fix will also help people adding ext3 to an existing filesystem. Look for ext3-0.0.5e.tar.gz on:

I previously wrote: > I have come across what appears to be a bug in __invalidate_buffers() > w.r.t. the change in ext3-0.0.6 using BH_JDirty instead of BH_Dirty > for buffers held in the journal. If invalidate_buffers() is called > on a device (LVM likes to do this a lot, for whatever reason), it yanks > JDirty buffers out from underneath the journal layer, and causes an > oops

Hi all, I've pushed my current set of ext3 diffs (against Marcelo's current tree) to http://people.redhat.com/sct/patches/ext3-2.4/dev-20030314/ This includes: 00-merged/ diffs recently merged into 2.4 10-core-fixes-other/ misc fixes/tweaks from akpm, adilger 11-core-fixes-sct/ misc fixes/tweaks from sct 20-tytso-updates/ Ted's recent updates 21-updates-sct/ recent sct diffs

[ Tried to check the archives but the website seems to be down or something ] On one of our installations, I am seeing messages such as: EXT3-fs warning (device ide0(3,9))): ext3_free_inode: bit already clearned for inode 14 Anybody know exactly what they mean? These would be on a 0.0.6a system. b.

I previously wrote: > OK, my previous patch cleans up the ASSERT for invalidate_buffers() > (modulo the fact that it was missing a ')' at the end of the line) > but it hasn't really fixed the whole problem. If a file write is in > progress when invalidate_buffers() is called, I get an oops: > The oops is caused from __invalidate_buffers() calling put_last_free(bh) >

---------- Forwarded Message ---------- Subject: ext3 for 2.4 Date: Thu, 17 May 2001 21:20:38 +1000 From: Andrew Morton <andrewm@uow.edu.au> To: ext2-devel@lists.sourceforge.net, "Peter J. Braam" <braam@mountainviewdata.com>, Andreas Dilger <adilger@turbolinux.com>, "Stephen C. Tweedie" <sct@redhat.com> Cc: linux-fsdevel@vger.kernel.org Summary:

Hi, ext3-0.0.5d.tar.gz is now up on ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ and ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ as patches against 2.2.18. This only contains the kernel bits: we're in the process of syncing up on some e2fsprogs so I'll do another release shortly once we've got all of the pending changes for the user-mode tools assembled. This release is mostly

Hi all, ext3-0.0.6b is now available at the usual places: ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ and ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ The only significant change in this release is the fix to the orphan list recovery, and that fix also affects e2fsprogs, so please pick up the new e2fsprogs from the same directory when you grab the ext3 release. I've put tarballs,

If a Xen guest has a bootloader configured, then it will fail to start on a blktap image. The problem is blkdev_uname_to_file, which cannot parse the "tap:aio:$filename" image strings: it tries to split the string apart at ":" and assign the result to a 2-tuple, and this results in a python error if the split results in three or more strings. The fix is to split only at the

Hi all, ext3-0.0.7a is now out, at the usual places: ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ and propagating now from ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ This fixes one major bug in ext3 recovery for metadata-only journaling. Because recovery can also happen in e2fsck, users should also upgrade to at least e2fsprogs-1.21-WIP-0601 (also provided at the above ftp sites).

Well.... you might remember that I have had problems will my NFS fileserver that run ext3 with data=journal. The filesystem corruption now seems too be solved with the patch (plus amendment) that I posted, so I am happy about that... but there is more. I have known for a while that ext3 doesn't behave very well when the journal fills up. If it finds that the journal is full, and the

Started with buffer.c v1.19. Reversing change works for me in linux-2.4.6. Loaded 16705 symbols from /lib/modules/2.4.6-pre3/System.map. Symbols match kernel version 2.4.6. Loaded 256 symbols from 12 modules. Linux version 2.4.6-pre3 (root@home1) (gcc version 2.95.3 20010315 (release)) #2 Wed Jun 13 19:53:28 EDT 2001 ----- SNIP ------- VFS: Disk change detected on device ide1(22,64) Assertion

I got this error in my log reports this morning, from the machine I use as my firewall. This is the first time it has occurred, but the machine is running a very new kernel: Linux fendrian.rimspace.net 2.6.0-test11-fendrian #1 Wed Dec 10 22:25:59 EST 2003 i486 GNU/Linux The kernel was up to date as per the CVS repository at that point. This was just before the CDROM_SEND_PACKET IOCTL fix went

Hi, I'm not sure if this is apprriate or not, but here goes anyway. The patch below updates MAINTAIER address Individuals (Only Andrew :): osdl.org -> linux-foundation.org Lists: osdl.org -> lists.osdl.org I assume the latter will change at some stage, but at least with this change the osdl/linux-foundation lists are consistent. Signed-off-by: Simon Horman

I am trying to obtain adjusted means and standard errors for a three way ANOVA I have three effects, two continuous; fire frequency and annual precipitation, and one categorical; soil type in an unbalanced design. I am testing the effect of annual precipition (AP), soil type (ST), and fire frequency (FF) on stem count (SCt) My data table looks as such: ST FF AP SCt 3 Coy

Hi Matthias, On 6/30/23 15:40, Matthias Leopold via samba wrote: > Can someone explain what is happening or where I need to tune? this is by design. :) The only reliable way (lacking S4U2SELF support) to get group membership for an AD user, is using the group list the DC passes along to us as part of the authentication process. We're trying extra hard to store this data *persistently*

Hi, Is there a way to tell / narrow down if an issue with errors like below are due to a bad cable or bad port multiplier ? The disks in a particular cage are throwing errors like these below. (RELENG9 from today) siis0 at pci0:5:0:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x02 hdr=0x00 vendor = 'Silicon Image, Inc.' device = 'SiI 3124 PCI-X Serial

Fellow riders of the bleeding edge of ext3 technology, I've been playing with ext3 on my workstation. For the most part it has worked very well, but right now I have a non-functional system. I've got patches out the wazoo on this kernel - 2.2.18 + Alan's 2.2.19pre13 + ext3-0.0.6a + i2c-2.5.5 + lm_sensors-2.5.5 + udf-0.9.3. Here is the output I get: EXT3-fs: WARNING: recovery

On 19/03/18 14:01, Morgan Read wrote: > Hello list > > I've been running the following command, first in fc20 and then now > (since the beginning of March) in fc26: > now=$(date +"%Y%m%d-%H%M"); sudo rsync -ahuAESX -vi /home/ > /run/media/readlegal/Backup/home > > /run/media/readlegal/Backup/rsync-changes_$now > > Since the move to fc26, this