search for: diskio

The disk number is set twice in diskio.c/edd_rdwr_sectors() this patch removes the redundant setting. diff --git a/core/fs/diskio.c b/core/fs/diskio.c index 481b59b..38d3da3 100644 --- a/core/fs/diskio.c +++ b/core/fs/diskio.c @@ -163,8 +163,6 @@ static int edd_rdwr_sectors(struct disk *disk, void *buf, memset(&reset, 0, siz...

...is.org/os/community/dtrace/scripts/) written by Brendan Gregg to look at the IO operations of my application. When I was running my test-program on a UFS filesystem I could see both read and write operations like: UID PID D BLOCK SIZE COMM PATHNAME 203803 4436 R 6016592 16384 diskio <none> 203803 4436 W 3448432 16384 diskio <none> 203803 4436 R 5510832 16384 diskio <none> 203803 4436 W 4652608 16384 diskio <none> But when I''m running my program on a ZFS file-system, I can only see the read io transfers: UID PID D B...

...2dc83d1191bb2f90b4d4d0ae3d37d6 > Author: Michal Soltys <soltys at ziu.info> > AuthorDate: Wed, 13 Oct 2010 10:57:36 +0200 > Committer: Michal Soltys <soltys at ziu.info> > CommitDate: Wed, 13 Oct 2010 10:57:36 +0200 > > disklib: make CHS calculation match core/fs/diskio.c > > Signed-off-by: Michal Soltys <soltys at ziu.info> > I note that this code still: a) duplicates the code between read and write, and b) doesn't check for CHS overflow. This is particularly critical for write, obviously, since we could corrupt a disk. -hpa

...cache themselves. The problem is that the same cache could be again initialized later, then invalidating the previous one. This patch fixes this. Problem found while auditing the code. Signed-off-by: Raphael S. Carvalho <raphael.scarv at gmail.com> --- core/fs/cache.c | 2 ++ core/fs/diskio.c | 1 + core/fs/fs.c | 5 +++-- core/include/fs.h | 1 + 4 files changed, 7 insertions(+), 2 deletions(-) diff --git a/core/fs/cache.c b/core/fs/cache.c index 3b21fc2..798c622 100644 --- a/core/fs/cache.c +++ b/core/fs/cache.c @@ -55,6 +55,8 @@ void cache_init(struct device *dev, i...

I''ve been getting a compile error when building the ''next-rc'' branch of btrfs-unstable. CC fs/btrfs/disk-io.o fs/btrfs/disk-io.c: In function ‘btree_migratepage’: fs/btrfs/disk-io.c:716: error: called object ‘0u’ is not a function make[2]: *** [fs/btrfs/disk-io.o] Error 1 make[1]: *** [fs/btrfs] Error 2 make: *** [fs] Error 2 Line 716 of fs/btrfs/disk-io.c is:

...me places that sector is 512. This function is quite helpful if you are going to read/write a range of bytes to/from the stack without creating stack overflows for free. I think this is the safer patch of the three. Signed-off-by: Frediano Ziglio <frediano.ziglio at citrix.com> --- core/fs/diskio.c | 80 +++++++++++++++++++++++++++++++++++++++++++-- core/fs/ext2/ext2.c | 2 +- core/fs/fat/fat.c | 2 +- core/fs/iso9660/iso9660.c | 8 ++-- core/fs/ntfs/ntfs.c | 4 +- core/include/disk.h | 2 + 6 files changed, 87 insertions(+), 11 deletions(...

Here is a partial patch that I'm using to illustrate a few questions that I have. Looking at the gpllib write_sectors (com32/gpllib/disk/write.c) it looks like the allocated size is wrong; size is in sectors so we should adjust the alloc/memcpy by size*SECTOR. Also, comparing core/diskio.c it looks like the registers aren't even setup right. In the patch below I put an #if 0 around the old code to demonstrate how it differs from diskio.c I also added a call to get_drive_parameters() so that it would be like the gpllib/read.c However, it would probably be best to not have to ca...

...lives in). get_fs_info is a function pointer that will be later hooked to a function from ldlinux.c32. get_fs_info is expected to return a fs_info structure given the MultiFS path. Signed-off-by: Raphael S. Carvalho <raphael.scarv at gmail.com> --- core/fs/cache.c | 2 +- core/fs/diskio.c | 26 ++++++++++++---- core/fs/diskio_bios.c | 40 ++++++++++++++----------- core/fs/fs.c | 22 +++++++++++--- core/fs/readdir.c | 9 +++++- core/include/multifs.h | 61 ++++++++++++++++++++++++++++++++++++++ core/multifs.c | 76 +++++++++++++++++++++++++...

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

...ithin the file, write 8192 bytes data, and fsync or fdatasync. We presume the data was not written to the corresponding disk before returning from fsync or fdatasync syscall on the evidence as follows: 1. The response time of fsync() and fdatasync() was extremely short. We use the "diskio" tool, which is downloadable from OSDL page (http://developer.osdl.jp/projects/doubt/). The program showed that the response time was under 10 microseconds. This time cannot be achieved with data transfer on IDE and PCI bus! 2. The IDE writing routine ide_start_dma() was not called...

Hi, Sorry for writing so many messages. I am doing a license review for syslinux in Debian and I've stumbled on the following files: * efi/console.c * efi/derivative.c * efi/diskio.c * efi/main.c * efi/mem.c * efi/pxe.c * efi/tcp.c * efi/udp.c All of them start with /* * Copyright 2011-2014 Intel Corporation - All Rights Reserved */ with no further indication of any license. This header was explicitly added to all of those files in one commit [1]. Can somone clarify...

From: Raphael S. Carvalho <raphael.scarv at gmail.com> My commit 09f4ac33 broke 'com32/lib/syslinux/disk.c' __lowmem doesn't work for declarations outside the core. Using __lowmem outside the core wouldn't have the desired effect, then lmalloc must be used instead to store dapa into the correct section (".lowmem"). Reported-by: Dark Raven <drdarkraven at

I've been playing with the Win32 SYSLINUX, and it fails if you're not using NT or 2K or XP. There are some differences when using it under Win95/98/ME, but is there any reason that this program couldn't just have a different codepath for those older version of Windows? Alex Pavloff - apavloff at esatechnology.com ESA Technology ---- www.esatechnology.com ------- Linux-based

This set of patches add some support for sector size >512. Currently it fixes extlinux, MBR for GPT and ext partitions. Other code is unaffected. This set of patches has been tested on a read Dell machine running a beta firmware.

...7 at 5:18 PM, Lukas Schwaighofer via Syslinux <syslinux at zytor.com> wrote: > Hi, > > Sorry for writing so many messages. I am doing a license review for > syslinux in Debian and I've stumbled on the following files: > * efi/console.c > * efi/derivative.c > * efi/diskio.c > * efi/main.c > * efi/mem.c > * efi/pxe.c > * efi/tcp.c > * efi/udp.c > > All of them start with > /* > * Copyright 2011-2014 Intel Corporation - All Rights Reserved > */ > with no further indication of any license. This header was explicitly > added t...

I'm trying to use systemtap to monitor per process diskio performance, however when trying to start stap it says I need kernel debug packages installed. Where can I find the kernel-xen-debuginfo and kernel-debuginfo-common packages for 5.1? Greets, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ce...

...ake bios efi64 'make efi64' failed with: ld -T /tmp/syslinux/efi/x86_64/syslinux.ld -Bsymbolic -pie -nostdlib -znocombreloc -L/usr/lib64 --hash-style=gnu -m elf_x86_64 /usr/lib64/crt0-efi-x86_64.o -E --strip-debug -o syslinux.so mem.o adv.o pxe.o fio.o console.o main.o derivative.o vesa.o diskio.o udp.o tcp.o /tmp/syslinux/efi64/core/codepage.o /tmp/syslinux/efi64/efi/../core//debug.o /tmp/syslinux/efi64/efi/../core//writestr.o /tmp/syslinux/efi64/efi/../core//init.o /tmp/syslinux/efi64/efi/../core//path.o /tmp/syslinux/efi64/efi/../core//cleanup.o /tmp/syslinux/efi64/efi/../core//serirq.o...

On 16 Jul 2019, at 11.15, Ralf Hildebrandt via dovecot <dovecot at dovecot.org> wrote: > > * Timo Sirainen via dovecot <dovecot at dovecot.org>: > >>> And alas, I had a look at the monitoring and found that disk IO has >>> increase A LOT after the update: https://www.arschkrebs.de/images/dovecot-disk-io-increase.png >>> >>> I zoomed in

...com32/lib/syslinux/multifs_utils.c | 91 +++++++++++ com32/{chain => lib/syslinux}/partiter.c | 6 +- com32/{chain => lib/syslinux}/utility.c | 2 +- core/bios.c | 11 ++ core/fs/cache.c | 2 +- core/fs/diskio.c | 28 +++- core/fs/diskio_bios.c | 40 ++--- core/fs/fs.c | 21 ++- core/fs/readdir.c | 8 +- core/include/multifs.h | 50 ++++++ core/multifs.c...

On Sat, 29 Jun, at 01:57:58AM, Igor Sverkos wrote: > Hi, > > Matt Fleming wrote: > > On Tue, 25 Jun, at 01:52:00PM, Helmut Hullen wrote: > >> Thanks - now it crashes later ... > > > > What crash are you seeing? > > > >> I don't have the ia64 files which are needed for a complete binary. But > >> maybe that's only my special