similar to: [Bug 1502] rsync error: error in rsync protocol data stream (code 12) at io.c(836)

https://bugzilla.samba.org/show_bug.cgi?id=1502 Summary: rsync error: error in rsync protocol data stream (code 12) at io.c(836) Product: rsync Version: 2.6.2 Platform: x86 OS/Version: Linux Status: NEW Severity: blocker Priority: P3 Component: core AssignedTo: wayned@samba.org

Hi ! My system is RH7.2 with Adaptec/DPT/I2O drivers (http://people.redhat.com/tcallawa/dpt/). There is a 2 disk RAID 1 array which had no disk fail. Several partition on it: Filesystem Size Used Avail Use% Mounted on /dev/sda1 1.9G 435M 1.4G 24% / /dev/sda2 13G 3.2G 9.1G 26% /home none 504M 0 503M 0% /dev/shm At this time, all

https://bugzilla.samba.org/show_bug.cgi?id=1457 ------- Additional Comments From mwang@unixlabplus.com 2004-06-13 12:05 ------- The same problem is duplicated on AIX 5.2 with current patch level 02. It appears that the problem occurs for large files. In the test shown below, it is 4.6GB. This happens for rsync 2.5.4 using the IBM build:

https://bugzilla.samba.org/show_bug.cgi?id=1764 Summary: dry-run does not show changes in owner / group, permission, or timestamp Product: rsync Version: 2.6.3 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

rsync does not sync the timestamp on symlink (Solaris 8). It is probablly due to the limitation of Unix implementation of symlink, but I would like to know why rsync/Unix does not do this, and what we can do about it. Is the conclusion that "rsync syncs everything except the timestamp on symlink"? Why do I need timestamp on symlink? Supposed something stopped working because something

Hi, i am seeing a crash in ext3_new_block quiet often today on 2.2.19 0.0.7a fsck 1.21 ksymoops 2.3.4 on i686 2.2.19. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /boot/System.map-2.2.19 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the

Just wondering if someone could help me debug this: I was moving data from an ATARAID (via Promise FastTrack100 Controller) into the LVM device below: 58,1: # cat /proc/lvm/VGs/foo3/LVs/bar name: /dev/foo3/bar size: 476315648 access: 3 status: 1 number: 0 open: 1 allocation: 0 device: 58:01 # /sbin/pvscan pvscan -- reading all physical volumes

I recently bought 2 different USB flash disks. These are some cheap no-name devices. Their parameters: bytes C/H/S ID 4194304512 509/255/63 Vendor: Generic Model: USB Flash Drive Rev: 1.00 ANSI SCSI revision: 02 4288676352 1023/132/62 Vendor: USB Model: USB 2.0 Rev: 1.00 ANSI SCSI revision: 02 When I put a FAT32 filesystem on them,

The whole loop=0,1,2 thing was kind of odd and not very self explanatory. I''ve replaced it with a list_for_each_entry on space_info->block_groups. If we have a hint we just jump into the loop with the block group and start looking for space. If we don''t find anything we start at the beginning and start looking. We never come out of the loop with a ref on the block_group

Hello, So there is an odd case where we can possibly return -ENOSPC when there is in fact space to be had. I think I finally have a hold on what the problem is, it only happens with Metadata writes, and happens _very_ infrequently. What has to happen is we have to allocate have allocated out of the first logical byte on the disk, which would set last_alloc to first_logical_byte(root, 0), so

Yan Zheng hit a problem where we tried to remove some free space but failed because we couldn''t find the free space entry. This is because the free space was held within a bitmap that had a starting offset well before the actual offset of the free space, and there were free space extents that were in the same range as that offset, so tree_search_offset returned with NULL because we

After a bit of searching through these archives I haven't found quite my problem described yet, so let me bounce this off you guys: Red Hat 7.2, I run up2date whenever patches come out; right now I'm using kernel 2.4.9-21. Things have been quite pleasant for several months, but in the last week I have begun receiving the following error messages: Feb 22 08:06:27 medmeta kernel:

If we are looking for a cluster in a particularly sparse or fragmented block group, we will do a lot of looping through the free space tree looking for various things, and if we need to look at bitmaps we will endup doing the whole dance twice. So instead add the bitmap entries to a temporary list so if we have to do the bitmap search we can just look through the list of entries we''ve

Red Hat 2.2.19-6.2.12 + 0.0.7a + https://listman.redhat.com/pipermail/ext3-users/2001-November/002258.html (not tuned in /proc yet) + journal 4MB on each fs + 6 ext3 fs on raid1 (hda+hdc) + 1 ext3 fs on another disk not on raid1 (hdd) While untarring (tar zxf) a file that was on a ext3/raid1 onto hdd I got: ksymoops 2.3.4 on i686 2.2.19-6.2.12.g1. Options used -V (default) -k

the tree log recover code expects no free space cached before it executes. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 4/fs/btrfs/extent-tree.c 8/fs/btrfs/extent-tree.c --- 4/fs/btrfs/extent-tree.c 2010-05-11 14:15:29.174108554 +0800 +++ 8/fs/btrfs/extent-tree.c 2010-05-11 13:26:38.036107000 +0800 @@ -316,11 +329,6 @@ static int caching_kthread(void *data) if (!path)

I noticed a huge problem with the free space cache that was presenting as an early ENOSPC. Turns out when writing the free space cache out I forgot to take into account pinned extents and more importantly clusters. This would result in us leaking free space everytime we unmounted the filesystem and remounted it. I fix this by making sure to check and see if the current block group has a cluster

hiya! see the attached file for the resolved bug() call. my kernel spit out 185 messages like this: Mar 9 17:15:13 srck@trottelkunde attempt to access beyond end of device Mar 9 17:15:13 srck@trottelkunde 16:42: rw=0, want=0, limit=12289725 right before the bug(). this message didn't get parsed by ksymoops Mar 9 17:15:13 srck@trottelkunde Assertion failure in journal_start() at

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

Just to make sure somebody reacts (please) I'm forwarding this. Please cc me on replies as I'm not subscribed to this list. -------- Original Message -------- Subject: [RESEND] 2.4.20: ext3: Assertion failure in journal_forget()/Oops on another system Date: Wed, 04 Dec 2002 21:27:31 +0100 From: Andreas Steinmetz <ast@domdv.de> To: Linux Kernel Mailing List

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this