Tag Info

Hot answers tagged

42

Yes, theres a very plausible way to do this with device mapper. The device mapper can recombine block devices into a new mapping/order of your choosing. LVM does this. It also supports other targets, (some which are quite novel) like 'flakey' to simiulate a failing disk and 'error' to simulate failed regions of disk. One can construct a device which ...


12

For checking program's robustness in case their output fails, you can use the pseudodevice /dev/full, which always returns "ENOSPACE" when written to. $ dd if=/dev/zero of=/dev/full dd: writing to `/dev/full': No space left on device 1+0 records in 0+0 records out


9

STOP. Do nothing further until you fully understand what device special files are, what they mean to the operating system, and how they are created/managed. (hint: mknod -- this will probably help you fix your other problem too) In brief, a device file is an interface for sending commands/data to a device's driver, and receiving information back from it. ...


8

This really isn't feasible with modern disks. In the old days disks were essentially dumb devices (simplifying, but stick with me). The system would request data from a particular Cylinder (physically a ring on the disk), Head (2 heads per platter), and Sector (each ring had sector numbered from 1 to whatever). The controller told the disk to move to such ...


8

Use the blockdev command: Bytes: > time blockdev --getsize64 /dev/system/home 32212254720 real 0m0.004s user 0m0.001s sys 0m0.002s Sectors: > time blockdev --getsize /dev/system/home 62914560 real 0m0.006s user 0m0.001s sys 0m0.003s


6

Storing QEMU-images in a database is on many levels very impractical. Using an ordinary filesystem for the storage itself, and referencing the files from the database is a lot simpler - and will probably grant you what you're trying to achieve. If this doesn't work for you, I'd like to know more about what you're trying to achieve.


6

As with all things problematic. Asking for help usually solves it. Even when no-one answers the question. So the answers two fold. Apparently installing xen* stuff is not enough in Ubuntu. Blktap and stuff is separately packages and tapdisk userspace programs and blktap module is needed. Install blktap-utils and dependencies... You'll get tapdisk and with ...


6

I believe the tool you're looking for is kpartx. The general procedure is: List partitions in the disk image: kpartx -l /dev/vg0/mylv Add the partitions to device-mapper: kpartx -a /dev/vg0/mylv Mount the partition you're interested in: mount -o ro /dev/mapper/loop0p5 /mnt


4

mkfs -q /dev/ram1 X where X is the size in KB. You'd want 1048576 for 1GB.


4

The block device driver for ramdisks has the size set at the time the driver loads, using the ramdisk_size= parameter to specify the number of blocks (default blocksize = 1024 bytes, see ramdisk_blocksize= as well) to allocate to each ramdisk. If you're loading it as a module, you can use that parameter when loading the module, otherwise if it's built into ...


4

Depends on what you want to test. Using an LD_PRELOADed library, you can trick applications into thinking things like 'all writes fail with ENOSPC or EIO' for instance.


4

You can do that in oh so many interesting ways. See https://www.kernel.org/doc/Documentation/fault-injection/fault-injection.txt


4

Based on the above requirements, Ceph may be what you're after. http://ceph.newdream.net/ Ceph provides a distributed, POSIX-compliant file system, that you can mount as a block device using the Rados block device. This is implemented directly in modern Linux kernels (2.6.37+). There's even a Qemu/KVM storage driver which means you can mount Ceph ...


4

Yes, DRBD is the only replicated block device out there that can handle concurrent writes. If you plan to put a filesystem on top, it obviously needs to handle multiple writers as well, like GFS(2) and OCFS(2) do. Please note that if you can afford higher levels of abstraction for redundancy, you'll likely be much, much happier with file-level semantics, so ...


4

How does the RA setting get passed down the virtual block device chain? It depends. Let's assume you are inside Xen domU and have RA=256. Your /dev/xvda1 is actual LV on the dom0 visible under /dev/dm1. So you have RA(domU(/dev/xvda1)) = 256 and RA(dom0(/dev/dm1)) = 512 . It will have such effect that dom0 kernel will access /dev/dm1 with another RA ...


3

The logic for when Linux applies read-ahead is complicated. Starting in 2.6.23 there's the really fancy On-Demand Readahead, before that it used a less complicated prediction mechanism. The design goals of read-ahead always include not doing read-ahead unless you have a read access pattern that justifies it. So the idea that the stripe size is a relevant ...


3

Virtualization on NFS is a well established technology. There are benefits and disadvantages to NFS and block, but you can't pick and choose them. Deduplication, volume resizing, and thin provisioning on block devices are all mature technologies that work fine. Same for NFS.


3

If you want distributed image storage, QEMU supports using images on Rados Block Devices (implemented using Ceph): http://ceph.newdream.net/2010/12/rbd-upstream-updates/


3

ZFS in conjunction with its ARC behave the way you want it. But the Linux implementation is done in userspace (FUSE) due to licensing concerns and I would not trust a performance-sensitive application with high uptime requirements to FUSE implementations. There is also BTRFS which is quite similar to ZFS in its concepts so the caching behavior might be ...


3

LV -> dm or md device -> sdX -> block layer This is how an IO goes in case of LVM. If you run blktrace or systemtap, it should be clearer.


3

It's probably /dev/sdb given the sizes you listed, but you can find out by running df -h. I keep my data in /data and here is my relevant output: > df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 70G 18G 49G 27% / /dev/sdc1 932G 682G 250G 74% /data In my case that means that the one I should be altering for ...


3

What you call a "storage device" is more generally referred to as a "block device". If you're writing scripts that interact with block devices, it seems like your best bet is to enumerate things in /sys/class/block and work from there, or use the various entries in /dev/disk (in fact, it looks like the latter may be a better choice under RHEL5). This way ...


2

It looks like you're more looking for something like mount -t tmpfs -o size=1024m tmpfs mount_directory


2

First thing I would say, is you may need to reset your expectations of complexity. The subject for your question alone includes: distributed fault-tolerant network block device Each of these alone is generally a topic of at least moderate complexity. Combining all three of them, and you're not going to accomplish it without a little bit of work. I ...


2

Here are some things you could try. I don't know lvm internals, so I don't know if they'll make any difference. Try lvs instead of lvdisplay. Maybe it's faster since it looks for less information. Try running lvdisplay or lvs only once for all the volumes you're interested in. Since some information is stored per volume group, there will be less ...


2

df -P / | tail -n 1 | awk '/.*/ { print $1 }' Will return the root FS block device. Not necessarily the boot device though. Better question might be why you're not scanning SMART on all the disks in the server?


2

Know the answer harder to explain so I will do so in example. Say for the sake of this you have 3 block devices an you set your RA to say 4 (4*512 byte) assuming standard sector. If you were to say use a RAID-5 scheme using the 3 disks, any read that even touched a stripe on a unique disk would compound the RA by the factor you initially set block device RA ...


1

You are describing a SAN. If you want to build it yourself, you probably can, but I can't help you more than pointing you in the direction of ZFS. If you end up buying one from a storage vendor, you'll want to change the way you describe it. Here is a breakdown of what you're asking for: "A client's block device should write simultaneously to several ...


1

I have heard about a variant of the network block device (NBD) which supports replication: ENBD. However, I don't know about the status of that project. The website doesn't look as if it was still supported, though.


1

You could set up a RAID set using iSCSI devices but I'd be wary of doing this with asymmetric storage devices (which in the case of remote storage includes the network) - OTOH DRBD is explicitly designed to support such usage. Is there a reason you don't like DRBD? Have I failed in my research If you think that GFS is a replicating cluster ...



Only top voted, non community-wiki answers of a minimum length are eligible