similar to: ext3-2.4-0.9.5

An update to the ext3 filesystem for 2.4 kernels is available at http://www.uow.edu.au/~andrewm/linux/ext3/ The diffs are against linux-2.4.7 and linux-2.4.6-ac5. The changelog is there. One rarely-occurring but oopsable bug was fixed and several quite significant performance enhancements have been made. These are in addition to the performance fixes which went into 0.9.3. Ted has put out a

Patch against linux-2.4.8 is at http://www.uow.edu.au/~andrewm/linux/ext3/ The only changes here are merging up to 2.4.8 and the bigendian fix. linux-2.4.8-ac1 currently has ext3-0.9.3 which has no known crash-worthy bugs, but is old. I'm about to send Alan a diff which takes -ac up to 0.9.6. The changes between 0.9.3 and 0.9.6 may be summarised as: - Simplify the handling of

Postfix <http://www.postfix.org> does a chattr +S on its spool directory when it is installed on Linux. This is what is written in the postfix startup script -- # # LINUX by default does not synchronously update directories - # that's dangerous for mail. # if [ -f /usr/bin/chattr ] then CHATTR="/usr/bin/chattr +S" else CHATTR=echo fi -- Is this still required on ext3 ?

An update of the ext3 journalling filesystem for 2.4 kernels is available at http://www.uow.edu.au/~andrewm/linux/ext3/ Patches are against 2.4.6-ac1 and 2.4.6. Changes since 0.0.8 include: - Multiplied the version numbering by ten to cater for bugfix releases against the 0.9.0 stream. - The main thrust has been the removal of a number of changes in the core kernel which were required

In 2.4.20-pre5 an optimisation was made to the ext3 fsync function which can very easily cause file data corruption at unmount time. This was first reported by Nick Piggin on November 29th (one day after 2.4.20 was released, and three months after the bug was merged. Unfortunate timing) This only affects filesystems which were mounted with the `data=journal' option. Or files which are

Hello, We found that fsync and fdatasync syscalls sometimes don't sync data in an ext3 file system under the following conditions. 1. Kernel version is 2.6.6 or later (including 2.6.8.1 and 2.6.9-rc2). 2. Ext3's journalling mode is "data=journal". 3. Create a file (whose size is 1Mbytes) and execute umount/mount. 4. lseek to a random position within the file, write 8192 bytes

On Sat, Nov 7, 2015 at 5:03 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > How about 'strace mkfs.ext2 ..' and see if any system calls are > returning errors. That would show you whether nbd-client is throwing > errors away, or whether mkfs is getting the errors and ignoring them > (seems pretty unlikely, but you never know). > > After that, it'd be down

There's a big thread about filesystems on postfix-users@postfix.org Could you shed some light on that issue? ----- Forwarded message from Wietse Venema <wietse@porcupine.org> ----- From: wietse@porcupine.org (Wietse Venema) Date: Sun, 3 Feb 2002 07:53:26 -0500 (EST) To: Lawrence Greenfield <leg+@andrew.cmu.edu> Cc: Wietse Venema <wietse@porcupine.org>,

Hi all, I'm using dovecot since a few months and it works great. But a few days ago some coworkers mentioned that they got errormessages in their Mailapp. I searched in the logfiles and found this: Sep 14 12:07:35 Mailserv dovecot: IMAP(eckhard-ma-domain-com): fsync(/home/eckhard-ma-domain-com/mails/.INBOX.0002-Druckangebote von Druckereien.0002-schmerk

Hi, I have been doing some diskIO bench-marking of dom0 and domU (HVM). I ran into an issue where domU performed better than dom0. So I ran few experiments to check if it is just diskIO performance. I have an archlinux (kernel 3.5.0) + xen 4.2.2) installed on a Intel Core i7 Q720 machine. I have also installed archlinux (kernel 3.5.0) in domU running on this machine. The domU runs with 8 vcpus.

Hi all, First, my apologies if this is not the right forum for this... if there is a more appropriate place to make OpenSSH feature requests, or if this feature already exists, please let me know. Some background: My company makes an 'embedded' audio server box that runs Debian Linux, and one of the product's features is that users can upload files to the server via SSH, using their

Hi all, We are building a new system which is going to use ext3 FS. We would like to know more about the behavior of ext3 in the case of failure. But before I procede, I would like to share more information about our future system. * Our application always does an fsync on files * When symbolic links (more specifically fast symlink) are created, the host directory is also fsync'ed. * Our

Btrfs had some issues with fsync()''ing directories and fsync()''ing after renames. These three new tests cover the 3 different issues we were seeing. This breaks out the dmflakey stuff into a common helper to be shared between generic/311 and generic/321. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- V1->V2: rename test to generic/321 -removed an

I'm a newbie with a TDM11B. I've read the FAQs about linking /usr/src/linux-2.6 to /usr/src/linux-2.6.8-1.521 and /lib/linux-2.6 to /lib/linux-2.6.8-1.521 but still get a million errors and eventual abort during compile. Could someone point me in the right direction? I do a yum update every day and I'm using the CVS from 9/14/04. I'm also using an ASUS CUSL2 system board.

On Mon, Mar 5, 2018 at 8:21 PM, Paul Anderson <pha at umich.edu> wrote: > Hi, > > tl;dr summary of below: flock() works, but what does it take to make > sync()/fsync() work in a 3 node GFS cluster? > > I am under the impression that POSIX flock, POSIX > fcntl(F_SETLK/F_GETLK,...), and POSIX read/write/sync/fsync are all > supported in cluster operations, such that in

Something else that you might want to do is count the number of journal commits that are taking place, via a command like this: perf stat -e jbd2:jbd2_start_commit -a sleep 3600 This will count the number of jbd2 commits are executed in 3600 seconds --- i.e., an hour. If you are running some workload which is constantly calling fsync(2), that will be forcing journal commits, and those turn into

In order to improve the performance of fsync, we use the outstanding ordered extents to avoid looking up the checksum from the csum tree. But we didn''t filter out the ordered extents whose csum is still being calculated, when we got those ordered extents, we had to wait for the csum calculation. It made the performance dropped down suddenly. (On my box, it drop down from 56MB/s to

Hi, I have a question on fsync() and ext3's journaling modes. Assume that I call fsync(fd) on a file. If that file is in 'data=journal' mode, would the fsync() return once the data gets safely into the journal ? On the other hand, if that file is in 'data=writeback' mode, would the fsync() return only when the data gets safely into its actual location ? Any help is

Hello, Currently Dovecot (and any other application, which cares about e-mail delivery) does at least one fsync per mail delivery. Given that hard disk drives have a very limited IOPS, this effectively limits the maximum mail delivery performance to a very low value, under utilizing the available storage IO capacity. Calculating with an average mail size of 50 kB and an average consumer HDD

+Csaba. On Tue, Mar 6, 2018 at 2:52 AM, Paul Anderson <pha at umich.edu> wrote: > Raghavendra, > > Thanks very much for your reply. > > I fixed our data corruption problem by disabling the volume > performance.write-behind flag as you suggested, and simultaneously > disabling caching in my client side mount command. > Good to know it worked. Can you give us the