similar to: Use of journal->j_blk_offset

This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 the following unused global functions: - journal.c: __journal_internal_check - journal.c: journal_ack_err - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL's: - journal.c: journal_check_used_features -

A scsi error (caused possibly by a loose cable) has left the processes accessing my ext3 file system hung in an unkillable state after it triggered an assert in ext3's journaling layer. I assume my only recourse at this point is to reboot. Please correct me if I'm wrong. Log messages appended. Thanks, -Jim Nov 21 04:04:04 attila kernel: SCSI disk error : host 0 channel 0 id 5 lun 0

This patch contains the following possible cleanups: - make needlessly global functions static - journal.c: remove the unused global function __journal_internal_check and move the check to journal_init - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL's: - journal.c: journal_check_used_features -

I've been running into a kernel panic pretty consistently when using data=journal. This occurs during heavy IO, and is highly reproducible (only takes about 5 minutes of IO to cause it). The applications being used are MySQL, Postfix, and a mail filtering application which operates on postfix queue files using mmaped IO. Shortly before the crash, the following messages are logged: Mar

Hi, I am trying to maximize a utility function using optim. I have a problem with optim, since some of the values in the caw, mom, me and btm matrixes in the code bellow are missing. Is there a handy way just to skip the missing values in the loop? g <- 5 retp <- NULL object <- function (x) { b1 <- x[1] b2 <- x[2] b3 <- x[3] for(i in 1:nrow(ret)){ for(j

Getting this oops on one of our production servers pretty much hangs the server. Do we have a corrupted Journal? how would ewe rebuild it? Any idea how to recover from it? Assertion failure in journal_bmap() at journal.c:636: "ret != 0" invalid operand: 0000 CPU: 0 EIP: 0010:[journal_bmap+70/96] Not tainted EIP: 0010:[<c016b646>] Not tainted EFLAGS: 00010282

Hello. On a server running 2.4.25, I have the two following errors in the kernel logfile: Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) Unexpected dirty buffer encountered at do_get_write_access:618 (08:11 blocknr 920707) Should I worry about them (disk failure, filesystem damage) ? Thanks. As an addition what does the pair '08:11' means ? Is

Hello ext3-users-request, request ======= 2004-03-03 12:00:00 You writed======= >Send Ext3-users mailing list submissions to > ext3-users at redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/ext3-users >or, via email, send a message with subject or body 'help' to > ext3-users-request at redhat.com >

It's both in 2.6 and recent 2.6 (for RH ASS2.1 you'll probably need to copy the latest 2.4 defintion, but I don't care for obsolete junk). Index: src/super.c =================================================================== --- src/super.c (revision 1014) +++ src/super.c (working copy) @@ -799,7 +799,7 @@ /* get first two blocks */ for (i=0; i<2; i++) { - bhs[i] = getblk

This patch contains the following cleanups: - make needlessly global functions static - journal.c: remove the unused global function __journal_internal_check and move the check to journal_init - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL: - journal.c: journal_recover Signed-off-by: Adrian Bunk

Hello, I've got a problem that is not solved after an e2fsck. What happens is that the kernel (vanilla 2.6.12) does this: journal_bmap: journal block not found at offset 1036 on hda6 Aborting journal on device hda6. ext3_abort called. The filesystem is mounted with errors=panic, so the system reboots. At boot-up an e2fsck is run on /dev/hda6. Sometimes it finds errors, sometimes not.

Hello, I am not subscribed to this mailing list. My apologies if non-members are not allowed to post in this forum. I have a Linux-2.4.19pre10aa4 computer and I have seen an error message "Unexpected dirty buffer encountered at do_get_write_access:598 (03:05 blocknr 0)" appears in the log. With a little bit of research I found that this message is printed from fs/jbd/journal.c,

Hi there, I'm using RH7.2 (with the 2.4.9-30 kernal and it's required components) as a base for a server system running kernel 2.4.18. I've gone to this version to get around non-performing aic7xxx drivers in the stock 7.2 kernels, and updated gigabit ethernet drivers. I have a raid unit (Medea) attached to an Adaptec 3916, coming up as sdb. It has 2kb blocks, but the fault

Hi Stephen, I found a bug in JBD routine journal_create() in kernel 2.6, when I debug the OCFS v2 driver. mark_buffer_dirty() reports buffer_head is not uptodate. See following bug description. ------------------------------------------------------- OS: Linux Kernel 2.6.1 Plarform: IA32 Steps: 1. Build the ocfs v2 driver under kernel 2.6. 2. insert ocfs2.ko into kernel 2.6. 3. mkfs.ocfs2 -F

Hi, Michael I have met ext4 error when using vhost_scsi on arm64 platform, and suspect it is vhost_scsi issue. Ext4 error when testing virtio_scsi & vhost_scsi No issue: 1. virtio_scsi, ext4 2. vhost_scsi & virtio_scsi, ext2 3. Instead of vhost, also tried loopback and no problem. Using loopback, host can use the new block device, while vhost is used by guest (qemu).

Hi, Michael I have met ext4 error when using vhost_scsi on arm64 platform, and suspect it is vhost_scsi issue. Ext4 error when testing virtio_scsi & vhost_scsi No issue: 1. virtio_scsi, ext4 2. vhost_scsi & virtio_scsi, ext2 3. Instead of vhost, also tried loopback and no problem. Using loopback, host can use the new block device, while vhost is used by guest (qemu).

On Thu, Jun 01, 2017 at 01:03:25PM +0530, ABHISHEK PALIWAL wrote: > Hi Niels, > > No problem we wil try to backport that patch on 3.7.6. > > Could you please let me know in which release Gluster community is going to > provide this patch and date of that release? It really depends on when someone has time to work on it. Our releases are time based, and will happen even when a

Hi Niels, No problem we wil try to backport that patch on 3.7.6. Could you please let me know in which release Gluster community is going to provide this patch and date of that release? Regards, Abhishek On Wed, May 31, 2017 at 10:05 PM, Niels de Vos <ndevos at redhat.com> wrote: > On Wed, May 31, 2017 at 04:08:06PM +0530, ABHISHEK PALIWAL wrote: > > We are using 3.7.6 and on

Hi Team, I did some modification in glusterfs code and now able to modify the permission of maximum of files. But still 2 file's permission in 0600 1. cli.log 2. file which contains the mounting information for "mount -t glusterfs" command I will really appreciate, if some can point light on this area. Also is there any side effect of changing these permissions apart from other

I have installed the xen 3.1.0 x86_64 tarball compiled for RHEL5 on a RHEL5 system. The system in question was able to boot with the xen kernel that came with RHEL5. I untarred the tarball, and did cd /boot mkinitrd /boot/initrd-2.6.18-xen.img 2.6.18-xen The command exited properly and made a initrd image. The machine booted with a grub.conf entry like this: title Xen 3.1.0 root