search for: max_sectors_kb

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 17 Feb 2011 13:20:20 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=29302 > > Summary: Null pointer dereference with large max_sectors_kb > Product: IO/Storage > Version: 2.5 > Kernel Version: 2.6.36 - 2.6.38-rc5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 >...

...t (boots from iSCSI on 10G card to COMSTAR zfs volume) System also has Infiniband which provide another four (4) paths multipath is initialised in initramfs Kernel is 3.10.0-693.11.1.el7.x86_64 With respect to https://access.redhat.com/solutions/2437991 there is a recommendation to adjust the 'max_sectors_kb' for devices when seeing the kernel error I am encountering. To that end I have queried the /sys/block area for that information the below. For debugging, at boot, I have disabled multipathd service I wrote the below script to query /sys/block for block device information: ? # cat bin/max_sec...

Hi, What's the correct way to change configuration parameters for an iSCSI device? For example I/O scheduler, max_sectors_kb, etc... I could add commands to the S99local script: echo noop > /sys/block/sdb/queue/scheduler echo 64 > /sys/block/sdb/queue/max_hw_sectors_kb Unfortunately, iSCSI device names might change from sdb to, say, sdc (server reboot, iSCSI target reconnection). If this happens, customizati...

...s fine for single-device btrfs, so my guess is that btrfs trying to use one set of parameters for all devices on a filesystem and is therefore submitting out-of-spec write requests to the older 120 GB PATA drive. As I understand it, the relevant parameters are these: $ cat /sys/block/sdb/queue/max_sectors_kb 512 $ cat /sys/block/sdd/queue/max_sectors_kb 128 Is this a known issue? Is it specifically a btrfs issue? dmesg is attached.

...VMware or an iSCSI one. I set up two volumes (one for each card); one RAID6 and one RAID5. I used the default 64K block size and am trying various filesystems in tandem with it. I stumbled across the following recommendations on 3Ware's site: echo "64" > /sys/block/sda/queue/max_sectors_kb blockdev --setra 16384 /dev/sda echo "512" > /sys/block/sda/queue/nr_requests But am wondering if there are other things I should be looking at, including changing the IO scheduler. Any particular options I should use with filesystem creation to match up with my RAID block size?...

...d->d_name, ".") == 0 || strcmp(d->d_name, "..") == 0) { + continue; + } + + break; + } + + closedir(ffs); + + pstrcat(path, MAXPATHLEN, d->d_name); + pstrcat(path, MAXPATHLEN, "/queue/"); + + read_queue_limit(path, "max_sectors_kb", &bs->max_sectors); + read_queue_limit(path, "max_segments", &bs->max_segments); + read_queue_limit(path, "max_segment_size", &bs->max_segment_size); +} + static int hdev_open(BlockDriverState *bs, const char *filename, int flags) { BDRVRa...

...d->d_name, ".") == 0 || strcmp(d->d_name, "..") == 0) { + continue; + } + + break; + } + + closedir(ffs); + + pstrcat(path, MAXPATHLEN, d->d_name); + pstrcat(path, MAXPATHLEN, "/queue/"); + + read_queue_limit(path, "max_sectors_kb", &bs->max_sectors); + read_queue_limit(path, "max_segments", &bs->max_segments); + read_queue_limit(path, "max_segment_size", &bs->max_segment_size); +} + static int hdev_open(BlockDriverState *bs, const char *filename, int flags) { BDRVRa...

Hi all after being a silent reader for some time and not very successful in getting good performance out of our test set-up, I'm finally getting to the list with questions. Right now, we are operating a web server serving out 4MB files for a distributed computing project. Data is requested from all over the world at a rate of about 650k to 800k downloads a day. Each data file is usually

Hi, For virtio block device, actually there is no a hard limit for max request size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. But it doesn't work, because there is a default upper limitation BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. Weiping Zhang (2): blk-setting:

Hi, For virtio block device, actually there is no a hard limit for max request size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. But it doesn't work, because there is a default upper limitation BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. Weiping Zhang (2): blk-setting:

...queue_ra_entry = { - .attr = {.name = "read_ahead_kb", .mode = S_IRUGO | S_IWUSR }, + .attr = {.name = "read_ahead_kb", .mode = 0644 }, .show = queue_ra_show, .store = queue_ra_store, }; static struct queue_sysfs_entry queue_max_sectors_entry = { - .attr = {.name = "max_sectors_kb", .mode = S_IRUGO | S_IWUSR }, + .attr = {.name = "max_sectors_kb", .mode = 0644 }, .show = queue_max_sectors_show, .store = queue_max_sectors_store, }; static struct queue_sysfs_entry queue_max_hw_sectors_entry = { - .attr = {.name = "max_hw_sectors_kb", .mode = S_...

...queue_ra_entry = { - .attr = {.name = "read_ahead_kb", .mode = S_IRUGO | S_IWUSR }, + .attr = {.name = "read_ahead_kb", .mode = 0644 }, .show = queue_ra_show, .store = queue_ra_store, }; static struct queue_sysfs_entry queue_max_sectors_entry = { - .attr = {.name = "max_sectors_kb", .mode = S_IRUGO | S_IWUSR }, + .attr = {.name = "max_sectors_kb", .mode = 0644 }, .show = queue_max_sectors_show, .store = queue_max_sectors_store, }; static struct queue_sysfs_entry queue_max_hw_sectors_entry = { - .attr = {.name = "max_hw_sectors_kb", .mode = S_...

All, For our project, we bought 8 new Supermicro servers. Each server is a quad-core Intel cpu with 2U chassis supporting 8 x 7200 RPM Sata drives. To start out, we only populated 2 x 2TB enterprise drives in each server and added all 8 peers with their total of 16 drives as bricks to our gluster pool as distributed replicated (2). The replica worked as follows: 1.1 -> 2.1 1.2

tl;dr version: 3.0 produces “bio too big” dmesg entries and silently corrupts data in “meta-raid1/data-single” configurations on disks with different max_hw_sectors, where 2.6.38 worked fine. tl;dr side-issue: on-line removal of partitions holding “single” data attempts to create raid0 (rather than single) block groups. If it can''t get enough room for raid0 over all remaining disks, it