similar to: [PATCH] OCFS2: fdatasync should skip unimportant metadata writeout

Hi. In btrfs, fdatasync and fsync are identical. I think fdatasync should skip committing transaction when inode->i_state is set just I_DIRTY_SYNC and this indicates only atime or/and mtime updates. Following patch improves fdatasync throughput. #sysbench --num-threads=16 --max-requests=10000 --test=fileio --file-block-size=4K --file-total-size=16G --file-test-mode=rndwr

Hi Chris. I think it is needed to call mark_inode_dirty() when file size expands in order to flush metadata updates to HDD through sync() syscall or background_writeout(). Thanks. Signed-off-by: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp> diff -Nrup linux-2.6.29-rc3.org/fs/btrfs/file.c linux-2.6.29-rc3/fs/btrfs/file.c --- linux-2.6.29-rc3.org/fs/btrfs/file.c 2009-02-02

Hi. I introduced "is_partially_uptodate" aops for OCFS2. A page can have multiple buffers and even if a page is not uptodate, some buffers can be uptodate on pagesize != blocksize environment. This aops checks that all buffers which correspond to a part of a file that we want to read are uptodate. If so, we do not have to issue actual read IO to HDD even if a page is not uptodate

All, Please review the patches backported to 1.4 from mainline. Sunil

Hi. I got following BUG trace. This is violation of BUG_ON(!buffer_locked(bh)) check on submit_bh() function. In write_dev_supers(), if wait parameter is set and buffer_uptodate() check is negative, submit_bh() is executed and hit above BUG_ON. So I fixed this issue. Thanks. Jun 9 00:41:32 dl580 kernel: ------------[ cut here ]------------ Jun 9 00:41:32 dl580 kernel: kernel BUG at

Hello. I found bugs on error handlings in the functions arround the ext3 file system, which cause inadequate completions of synchronous write I/O operations when disk I/O failures occur. Both 2.4 and 2.6 have this problem. I carried out following experiment: 1. Mount a ext3 file system on a SCSI disk with ordered mode. 2. Open a file on the file system with O_SYNC|O_RDWR|O_TRUNC|O_CREAT

Linus, et al, Here are the ocfs2 updates for 2.6.31. It's a quiet cycle, almost completely composed of fixes. There is a nice performance improvement from Hisashi Hifumi for fdatasync. Please pull. Joel The following changes since commit b4348f32dae3cb6eb4bc21c7ed8f76c0b11e9d6a: Linus Torvalds (1): Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs are available in

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 Thu, 6 Feb 2020, Hisashi T Fujinaka wrote: > Built and passed tests on NetBSD-9_RC2 on amd64 and on NetBSD-current on > amd64. Issues with MacOS Catalina: > configure: error: *** working libcrypto not found, check config.log AFAIK MacOS no longer includes libcrypto or headers in the base operating system, so you'll either need to compile them yourself or install them via

On Fri, 7 Feb 2020 at 15:09, Hisashi T Fujinaka <htodd at twofifty.com> wrote: > > On Fri, 7 Feb 2020, Damien Miller wrote: > > > On Thu, 6 Feb 2020, Hisashi T Fujinaka wrote: > > > >> Built and passed tests on NetBSD-9_RC2 on amd64 and on NetBSD-current on > >> amd64. Issues with MacOS Catalina: > >> configure: error: *** working libcrypto not

On Wed, Feb 17, 2016 at 3:51 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote: > Sorry, I haven't been paying too much attention here, but I'm having > repeated failures when I tried this morning. > > NetBSD-current: > test_sshkey: ..................................[1] Segmentation fault > (core dumped) ${V} /home/htodd... > *** Error code 139 did it

On Tue, 16 Feb 2016, Hisashi T Fujinaka wrote: > On Wed, 17 Feb 2016, Darren Tucker wrote: > > > On Wed, Feb 17, 2016 at 3:51 AM, Hisashi T Fujinaka <htodd at twofifty.com> > > wrote: > > > Sorry, I haven't been paying too much attention here, but I'm having > > > repeated failures when I tried this morning. > > > > > >

On Tue, 16 Feb 2016, Hisashi T Fujinaka wrote: > On Wed, 17 Feb 2016, Damien Miller wrote: > > > > Core was generated by `test_sshkey'. > > > Program terminated with signal SIGSEGV, Segmentation fault. > > > #0 0x000000000041273e in cert_parse (key=0x7f7ff7b120c0, > > > certbuf=0x7f7ff7b16200, b=0x7f7ff7b161b0) at sshkey.c:1896 > > > 1896

I suspect this is because it is a 1.x application which was upgraded, but my migrations don''t "stick." If I Coder-iMac:patton colin$ rake db:migrate (in /Users/colin/Desktop/patton) == 20090217193953 AddLastYearToTarget: migrating ============================== == 20090217193953 AddLastYearToTarget: migrated (0.0001s) ===================== == 20090222192059 AddEditorToUser:

On Wed, 17 Feb 2016, Hisashi T Fujinaka wrote: > > This one is failing a test assetion - there should be some more useful > > output available from the test itself. > > I think it's this: > > test_hostkeys: > regress/unittests/hostkeys/test_iterate.c:163 test #1 "hostkeys_iterate all > with key parse" > ASSERT_INT_EQ(sshkey_load_public(

On Fri, 22 Jul 2016, Hisashi T Fujinaka wrote: > regress/unittests/test_helper/test_helper.c:162 > (gdb) p key > $1 = (struct sshkey *) 0x7037f9b120c0 > (gdb) p key->cert > $2 = (struct sshkey_cert *) 0x7037f9b1b080 > (gdb) p *key->cert > $3 = {certblob = 0x7037f9b162a0, type = 2, serial = 5, key_id = 0x7037f9b18090 > "julius", nprincipals = 1, >

On Wed, 17 Feb 2016, Hisashi T Fujinaka wrote: > > I need to make these error messages more user-friendly :( > > > > -24 is SSH_ERR_SYSTEM_ERROR, so it's likely failing to find/load the > > key for some reason. I'll make a patch to improve the error message, > > but in the meantime you could probably figure out the exact failure > > using

On Wed, 17 Feb 2016, Hisashi T Fujinaka wrote: > And in another "oh duh" moment, I think this dumped core on two different > machines and I sent you the bt from the wrong machine. Here's the one > from NetBSD-7. > > #0 0x00007f7ff630e55a in _lwp_kill () from /usr/lib/libc.so.12 > (gdb) bt > #0 0x00007f7ff630e55a in _lwp_kill () from /usr/lib/libc.so.12 >

On Wed, 29 Jun 2016, ?ngel Gonz?lez wrote: > On 29/06/16 22:57, Wallace Forman wrote: >> I used the latest version from here: >> >> http://www.mls-software.com/opensshd.html >> >> On my other (Windows 10) machine (on which openssh works), I have cygwin >> installed, but if ssh was using cygwin, I wasn't aware of it. I just ran >> ssh from the

Hi, I've been attempting to write a gui wrapper to launch ssh -X user at machine application I'm trying to launch ssh and connect to it with pipes so that my front end can enter the password if required (either from a cache or by popping up a dialogue box). I've been having problems with pipes though reading from ssh's stdout, for when it asks for the password. Before I go