similar to: Updated ext3 patch set for 2.4

There's a new set of ext2/3 patches for 2.4.21-pre5 available at: http://thunk.org/tytso/linux/extfs-2.4-update/extfs-update-2.4.21pre5-2 and in broken out form at: http://thunk.org/tytso/linux/extfs-2.4-update/broken-out-2.4.21pre5-2 New to this patch set include: * A kludge to help htree work well with Linux's NFS implementation * Allow the orlov allocator to be disabled via a

I've backported all of the bugfixes to the 2.5 dxdir/htree patches to 2.4, and have created a new set of patches for Linux 2.4.21rc5. At this point it *looks* like we've fixed all of the htree bugs that people have reported, including the brelse bug, the memory leak bugs, and the NFS compatibility problems. I've done *very* light testing, and things seem to work, but I'm now

Just looking through the 2.4.20pre changelogs, I see there's been a bunch of Ext3 patches since 2.4.19. I'm keen to take advantage of any bug fixes and performance improvements, but am nervous about using 2.4.20 until it's completed its release cycle. Is there any way to get a patch just containing the Ext3 changes? Are there any changes since 2.4.20 that are very important, either

Just out of curiosity: Is htree in 2.6.0-test11 ? -- Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916 Referat V a - Kommunikationsnetze - AIM. ralfpostfix

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

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, 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

On Mon, Nov 26, 2001 at 10:00:39PM +0800, Yusuf Goolamabbas wrote: > Hi Andrea, The following is a thread on ext3-users in which sct mentions > that this is due to a core VFS bug introduced in 2.4.10 which applies > ulimits to block devices. Maybe this could be due to some interaction > with your blockdevice in pagecache > > I don't know if you already have a fix in your

Hi all, ext3-0.0.5c is now up at: ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ and ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ The most important part of this release is the e2fsprogs: e2fsck now supports the journal changes for metadata-only journaling. Ted, I've changed around the use of jfs* include files in e2fsprogs quite heavily here. In each build directory --- the lib/ext2fs

I have spent hours on R in Windows 7. Just installed 2 days ago so the R package should be current. Currently I am using the RGui (64-bit) for Windows. I can not read an Excel file into R from my computer. Have hours on this. Completely crazy!! I have the XLConnect package loaded. I think it is loaded because when I enter: > loadedNamespaces() [1] "base"

Hi, ext3-0.0.6a has been uploaded to ftp.uk.linux.org:/pub/linux/sct/fs/jfs/ext3-0.0.6a.tar.gz and ftp.*.kernel.org:/pub/linux/kernel/people/sct/ext3/ext3-0.0.6a.tar.gz This version changes the way dirty buffers are marked to protect against device drivers which might block in the ll_rw_block() function. (Loop and lvm are examples.) It should also fix a rare but persistent report of

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,

Il 18/01/2016 12:09, Chris Murphy ha scritto: > What is the result for each drive? > > smartctl -l scterc <dev> > > > Chris Murphy > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > . > SCT Error Recovery Control command not supported

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

Il 17/01/2016 19:36, Alessandro Baggi ha scritto: > Il 17/01/2016 18:46, Brandon Vincent ha scritto: >> On Sun, Jan 17, 2016 at 10:05 AM, Matt Garman >> <matthew.garman at gmail.com> wrote: >>> I'm not sure what's going on with your drive. But if it were mine, >>> I'd want >>> to replace it. If there are issues, that long smart check

On Thu, 27 Oct 2016 11:25, Alessandro Baggi wrote: > Il 24/10/2016 14:05, Leonard den Ottolander ha scritto: >> On Mon, 2016-10-24 at 12:07 +0200, Alessandro Baggi wrote: >> > === START OF READ SMART DATA SECTION === >> > SMART Error Log not supported >> >> I reckon there's a <snip> between those lines. The line right after the >> first

I want to convert the last of my filesystems to ext3. The only one left is /boot. It is not very big however, only about 10MB itself. Any recommendations on what size journal to put a /boot filesystem of only 10-20MB? Oh, BTW: "tunefs -j -J size=..." is awesome. No more gyrations with dd, chattr, lilo -R, etc. Nice! One note however: even in Stephen's 1.20.WIP.sct-20010216

I've been thinking recently that we should re-enable DIR_INDEX in mke2fs by default. When it first came out, we had done this and were bitten by a few bugs in the code. However, this code has been in heavy use for several thousand filesystem years in Lustre, if not elsewhere, and I'm inclined to think it is pretty safe these days. Likewise, RHEL/FC have had RESIZE_INODE as a standard

I decided that I would try out 2.5.44, and I noticed that htree was merged. If I don't do the tune2fs -O dir_index, and e2fsck -D, the (exisintg) fs won't use htree, right? Once I do the tune2fs and e2fsck, will I still be able to go back to a non-htree kernel if needed? (Will a htree-ized fs work on a non-htree kernel?) I'm guessing that it won't. I've seen a 2.4 htree

Apologies for the newbie question: I have a (stock) 2.4.20 build (*not* -ac), and I'm trying to work with large ext3 directories. By large, I mean 160,000 files per directory. (Yes, I know it would be better in nested directories but such is life). I feel htree would benefit me. Having upgraded from an earlier version of 2.4, I don't see any change, and close reading of the 2.4 changelog