search for: 1048577

steps to reproduce: ./run guestfish -N disk:1536M <<EOF part-init /dev/sda mbr part-add /dev/sda p 1 1048577 part-add /dev/sda p 1048578 2097154 part-add /dev/sda p 2097155 -1 mkfs ext2 /dev/sda1 mkfs ext2 /dev/sda2 mkfs ext2 /dev/sda3 EOF qemu-img create -f raw test2.img 1520M ./run virt-resize --format raw --output-format raw --resize /dev/sda1=-2M --resize /dev/sda2=-8M --shrink /dev/sda3 --no-extra-...

See companion patch: Subject: [PATCH nbdkit] server: Move size parsing code (nbdkit_parse_size) to common/include This is the second part of the patch. It adds the new human_size_parse function to libnbd and then uses it for parsing --queue-size, --request-size and --sparse. The main complication here is that there was already a common/utils/human-size.h header which ends up (eventually)

...g/2006:00"..., 151) = 151 shutdown(14, 1 /* send */) = 0 poll([{fd=14, events=POLLIN}], 1, 2000) = 0 close(14) = 0 read(5, 0xbfffb313, 1) = -1 EAGAIN (Resource temporarily unavailable) close(15) = 0 semop(1048577, 0x79e6bc, 1 <unfinished ...> Thanks for your input Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20060818/520871ea/attachment-0002.html>

...in the primary group descriptors is on the bad block list If the block is really bad, the filesystem can not be fixed. You can remove this block from the bad block list and hope that the block is really OK. But there are no guarantees. Clear<y>? yes Bad block inode has an indirect block (1048577) that conflicts with filesystem metadata. CLEARED. Bad block inode has an indirect block (1048576) that conflicts with filesystem metadata. CLEARED. The bad block inode has probably been corrupted. You probably should stop now and run e2fsck -c to scan for bad blocks in the filesystem. Continue...

Hi, Me and my supervisor are interested in improving llvm's lit a little bit. Currently, there are few things, that seem to be not very convenient about the tool: * Having several RUN commands in a failing test, it's impossible to figure out, which of them actually caused the test to fail. We can output the number of the failing RUN line. * It would be nice to

...39; blocksize2.log; then + echo "filter should have dropped too-small trim" + exit 1 +fi + +# Test behavior on overlarge accesses. +$QEMU_IO -f raw -c 'w -P 11 1048575 4094305' -c 'w -z 1050000 1100000' \ + -c 'r -P 0 1050000 1100000' -c 'r -P 11 3000000 1048577' \ + -c 'discard 7340031 2097153' 'nbd+unix://?socket=blocksize1.sock' +$QEMU_IO -f raw -c 'w -P 11 1048575 4094305' -c 'w -z 1050000 1100000' \ + -c 'r -P 0 1050000 1100000' -c 'r -P 11 3000000 1048577' \ + -c 'discard 7340031 2097153'...

...cksize2.log; then + echo "filter should have dropped too-small trim" + exit 1 +fi + +# Test behavior on overlarge accesses. +$QEMU_IO -f raw -c 'w -P 11 1048575 4094305' -c 'w -z 1050000 1100000' \ + -c 'r -P 0 1050000 1100000' -c 'r -P 11 3000000 1048577' \ + -c 'discard 7340031 2097153' 'nbd+unix://?socket=blocksize1.sock' +$QEMU_IO -f raw -c 'w -P 11 1048575 4094305' -c 'w -z 1050000 1100000' \ + -c 'r -P 0 1050000 1100000' -c 'r -P 11 3000000 1048577' \ + -c 'discard...

Hi, We have file readahead to do asyn file read, but has no metadata readahead. For a list of files, their metadata is stored in fragmented disk space and metadata read is a sync operation, which impacts the efficiency of readahead much. The patches try to add meatadata readahead for btrfs. In btrfs, metadata is stored in btree_inode. Ideally, if we could hook the inode to a fd so we could use

Since v1: add the blocksize filter, add testsuite coverage of the log filter, several fixes to the log filter based on what adding tests revealed I'm still working on FUA flag support patches on top of this; the patches should all be committed in the same release, as we want to minimize the number of releases that cause a filter ABI/API bump Eric Blake (3): backend: Rework internal/filter

...node table at 983042 32254 free blocks, 16384 free inodes, 0 used directories Group 31: block bitmap at 1015808, inode bitmap at 1015809, inode table at 1015 810 32254 free blocks, 16384 free inodes, 0 used directories Group 32: block bitmap at 1048576, inode bitmap at 1048577, inode table at 1048 578 32254 free blocks, 16384 free inodes, 0 used directories Group 33: block bitmap at 1081344, inode bitmap at 1081345, inode table at 1081 346 32254 free blocks, 16384 free inodes, 0 used directories Group 34: block bitmap at 1114112, inode bitma...

After more than a month since v2 [1], I've finally got my FUA support series polished. This is all of my outstanding patches, even though some of them were originally posted in separate threads from the original FUA post [2], [3] [1] https://www.redhat.com/archives/libguestfs/2018-January/msg00113.html [2] https://www.redhat.com/archives/libguestfs/2018-January/msg00219.html [3]