search for: jounral

Hello everyone, Ok, I admit it - I'm an idiot. But it seemed the right thing to do at the time.... I'm running RH 6.2 with a 2.2.19ext3 (ext3 0.0.7). I wanted to try out the new 2.4 kernel line, so I upgraded modutils, gcc and few other things.. Compiled the kernel (did NOT patch it to ext3) and installed it and rebooted. Well, it didn't understand ext3 fs.. Ok... Boot back into

Hi all, Man page of tune2fs says that max journal size is 102,400 filesystem blocks, which translates to ~100MB with 1kb blocks or ~400MB with 4kb block. I wonder - why this limitation exists? Now that relatively cheap ssd devices exist (gigabyte iRam) that offer up to 4GB of space, it would be extremely useful to use whole capacity of such device for full data journaling. -- Jure Pe?ar

...t;> generic/578 generic/594 generic/607 generic/620 generic/628 generic/630 > >>> generic/636 generic/702 > >>> Failed 49 of 568 tests > >>> ``` > >>> > >>>> > >>>> JBD2_ABORT indicates a fatal error happens, either in jounral layer or > >>>> filesystem. And we should not commit any further transactions. > >>>> It seems that we may unify the behavior like: > >>>> > >>>> if (is_journal_aborted(journal)) > >>>> return -EROFS; > >>>>...

...generic/594 generic/607 generic/620 generic/628 generic/630 >>>>> generic/636 generic/702 >>>>> Failed 49 of 568 tests >>>>> ``` >>>>> >>>>>> >>>>>> JBD2_ABORT indicates a fatal error happens, either in jounral layer or >>>>>> filesystem. And we should not commit any further transactions. >>>>>> It seems that we may unify the behavior like: >>>>>> >>>>>> if (is_journal_aborted(journal)) >>>>>> return -EROFS; >&gt...

...ic/620 generic/628 generic/630 > >>>>> generic/636 generic/702 > >>>>> Failed 49 of 568 tests > >>>>> ``` > >>>>> > >>>>>> > >>>>>> JBD2_ABORT indicates a fatal error happens, either in jounral layer or > >>>>>> filesystem. And we should not commit any further transactions. > >>>>>> It seems that we may unify the behavior like: > >>>>>> > >>>>>> if (is_journal_aborted(journal)) > >>>>>&gt...

...not enough room for this transaction, and the fallocate will fail. The patch below extents & restarts the transaction as necessary while allocating space, and should work with even the smallest journal. This patch refers ext4 resize. Test: # mkfs.ocfs2 -b 4K -C 32K -T datafiles /dev/sdc ...(jounral size is 32M) # mount.ocfs2 /dev/sdc /mnt/ocfs2/ # touch /mnt/ocfs2/1.log # fallocate -o 0 -l 400G /mnt/ocfs2/1.log fallocate: /mnt/ocfs2/1.log: fallocate failed: Cannot allocate memory # tail -f /var/log/messages [ 7372.278591] JBD: fallocate wants too many credits (2051 > 2048) [ 7372.278597] (...

...generic/630 >>>>>>> generic/636 generic/702 >>>>>>> Failed 49 of 568 tests >>>>>>> ``` >>>>>>> >>>>>>>> >>>>>>>> JBD2_ABORT indicates a fatal error happens, either in jounral layer or >>>>>>>> filesystem. And we should not commit any further transactions. >>>>>>>> It seems that we may unify the behavior like: >>>>>>>> >>>>>>>> if (is_journal_aborted(journal)) >>>>...

fstest generic cases 347 361 628 629 trigger a same issue: When jbd2 enter ABORT status, ocfs2 ignores it and keep going to commit journal. This commit gives ocfs2 ability to handle jbd2 ABORT case. Signed-off-by: Heming Zhao <heming.zhao at suse.com> --- fs/ocfs2/alloc.c | 10 ++++++---- fs/ocfs2/journal.c | 5 +++++ fs/ocfs2/localalloc.c | 3 +++ 3 files changed, 14