2011/12/9 Ricardo Bánffy :
> Dec 9 01:06:21 adams kernel: [ 207.912535] usb 1-2.1: reset high
> speed USB device number 7 using ehci_hcd
That's usually a REALLY bad sign.
If you can remove the drive from the USB enclosure, I suggest you plug
it to onboard SATA port. That way at least you won't
Dec 9 01:05:38 adams kernel: [ 165.328507] usb 1-2.1: new high speed
USB device number 7 using ehci_hcd
Dec 9 01:05:38 adams mtp-probe: checking bus 1, device 7:
"/sys/devices/pci:00/:00:1d.7/usb1/1-2/1-2.1"
Dec 9 01:05:39 adams mtp-probe: bus: 1, device: 7 was not an MTP device
Dec 9
Christoph Hellwig wrote:
> On Fri, Dec 09, 2011 at 09:40:35AM +0800, Li Zefan wrote:
>> To reproduce the bug:
>>
>> # touch /mnt/tmp
>> # stat /mnt/tmp | grep Change
>> Change: 2011-12-09 09:32:23.412105981 +0800
>> # chattr +i /mnt/tmp
>> # stat /mnt/tmp | grep Change
>> Ch
On Fri, Dec 09, 2011 at 09:40:35AM +0800, Li Zefan wrote:
> To reproduce the bug:
>
> # touch /mnt/tmp
> # stat /mnt/tmp | grep Change
> Change: 2011-12-09 09:32:23.412105981 +0800
> # chattr +i /mnt/tmp
> # stat /mnt/tmp | grep Change
> Change: 2011-12-09 09:32:43.19810529
To reproduce the bug:
# touch /mnt/tmp
# stat /mnt/tmp | grep Change
Change: 2011-12-09 09:32:23.412105981 +0800
# chattr +i /mnt/tmp
# stat /mnt/tmp | grep Change
Change: 2011-12-09 09:32:43.198105295 +0800
# umount /mnt
# mount /dev/loop1 /mnt
# stat /mnt/tmp
> Care to share you rsync script?
Sure. It's a little raw, and makes some assumptions about my environment, but
it does the job other than the fact that it takes weeks to run. :)
In the below example, the "main" or source FS is mounted at "/mnt/btrfs", the
"backup" or target FS at "/mnt/btrf
Hi Chris,
This was on 3.2-rc2 but I tried with rc4 and it segfaulted again. I
think the traces were the same but I've rebooted and can't say for
sure.
David
On Thu, Dec 8, 2011 at 11:45 AM, Chris Mason wrote:
> Which kernel is this? This looks like one I recently fixed.
>
> -chris
>
> On Thu, De
On Thu, Dec 08, 2011 at 05:39:16PM +, Jeremy Sanders wrote:
> On 08/12/11 17:23, Chris Mason wrote:
> >On Thu, Dec 08, 2011 at 04:57:12PM +, Jeremy Sanders wrote:
> >>On 08/12/11 15:32, Chris Mason wrote:
> >>>On Thu, Dec 08, 2011 at 03:19:38PM +, Jeremy Sanders wrote:
> Hi - I'm tr
On Thu, Dec 08, 2011 at 01:56:59PM -0600, BJ Quinn wrote:
> >As soon as there's something that can be tested, you'll find it on this
> >list.
>
> Great, I'd love to try it. I spent a lot of time with ZFS and the zfs
> send/recv functionality was very convenient.
>
> Meanwhile, does anyone kno
>As soon as there's something that can be tested, you'll find it on this list.
Great, I'd love to try it. I spent a lot of time with ZFS and the zfs
send/recv functionality was very convenient.
Meanwhile, does anyone know how I can change the UUID of a btrfs partition or
are there any other s
Which kernel is this? This looks like one I recently fixed.
-chris
On Thu, Dec 08, 2011 at 11:06:47AM -0800, David Marcin wrote:
> raid10 metadata and data filesystem. dmesg log follows. The system
> is unable to unmount the filesystem after this occurs.
>
> Filesystem mounted at/mnt/btrfs wi
Hi everyone,
The for-linus branch of the btrfs repository:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Has a few more fixes. The most notable here are two more patches from
Alexandre's batch of allocator fixes. The other two fix corner cases in
the state code
On Thursday, 08 December, 2011 10:00:54 Stephane CHAZELAS wrote:
> Because of the same uuid, the btrfs commands like filesystem
> show will not always give sensible outputs. I tried to rename
> the fsid by changing it in the superblocks, but it looks like it
> is alsa included in a few other places
raid10 metadata and data filesystem. dmesg log follows. The system
is unable to unmount the filesystem after this occurs.
Filesystem mounted at/mnt/btrfs with -o compress,degraded
Command: btrfs device delete missing /mnt/btrfs
[ 283.398222] [ cut here ]
[ 283.398289]
On 08/12/11 17:23, Chris Mason wrote:
On Thu, Dec 08, 2011 at 04:57:12PM +, Jeremy Sanders wrote:
On 08/12/11 15:32, Chris Mason wrote:
On Thu, Dec 08, 2011 at 03:19:38PM +, Jeremy Sanders wrote:
Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
(Fedora 16, x8
On Thu, Dec 08, 2011 at 04:57:12PM +, Jeremy Sanders wrote:
> On 08/12/11 15:32, Chris Mason wrote:
> >On Thu, Dec 08, 2011 at 03:19:38PM +, Jeremy Sanders wrote:
> >>Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
> >>(Fedora 16, x86_64, dual-core), where after
On 08/12/11 15:32, Chris Mason wrote:
On Thu, Dec 08, 2011 at 03:19:38PM +, Jeremy Sanders wrote:
Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
(Fedora 16, x86_64, dual-core), where after a few hours of writing, it
switches from writing with several threads to w
On 08.12.2011 17:28, BJ Quinn wrote:
>>> At any rate, was someone saying that some work had already started on
>>> something like btrfs send?
>
>> That's right.
>
> Google tells me that someone is you. :)
>
> What Google wouldn't tell me though was whether you have something I could
> test?
>> At any rate, was someone saying that some work had already started on
>> something like btrfs send?
>That's right.
Google tells me that someone is you. :)
What Google wouldn't tell me though was whether you have something I could test?
-BJ
--
To unsubscribe from this list: send the line
2011-12-08, 10:49(-05), Phillip Susi:
> On 12/7/2011 1:49 PM, BJ Quinn wrote:
>> What I need isn't really an equivalent "zfs send" -- my script can do
>> that. As I remember, zfs send was pretty slow too in a scenario like
>> this. What I need is to be able to clone a btrfs array somehow -- dd
>> w
On 08.12.2011 17:07, BJ Quinn wrote:
> At any rate, was someone saying that some work had already started on
> something like btrfs send?
That's right.
-Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majord
>No, btrfs send is exactly what you need. Using dd is slow because it
>copies unused blocks, and requires the source fs be unmounted and the
>destination be an empty partition. rsync is slow because it can't take
>advantage of the btrfs tree to quickly locate the files (or parts of
>them) that
On 07.12.2011 21:40, Kai Krakow wrote:
> Scrubbing reports 1 uncorrectable error. I have this error since my system
> froze due to some xorg graphic driver instability (was trying out SNA
> acceleration for sandybridge).
>
> The problematic file seems to be in /usr/portage but scrubbing doesn't
On 12/7/2011 1:49 PM, BJ Quinn wrote:
What I need isn't really an equivalent "zfs send" -- my script can do
that. As I remember, zfs send was pretty slow too in a scenario like
this. What I need is to be able to clone a btrfs array somehow -- dd
would be nice, but as I said I end up with the iden
On 08/12/11 15:32, Chris Mason wrote:
On Thu, Dec 08, 2011 at 03:19:38PM +, Jeremy Sanders wrote:
Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
(Fedora 16, x86_64, dual-core), where after a few hours of writing, it
switches from writing with several threads to w
On Thu, Dec 08, 2011 at 09:12:34AM -0200, Ricardo Bánffy wrote:
> Hi folks.
>
> Last night one of the USB attached disks malfunctioned during a
> balance. I strongly suspect the drive will die soon. A couple hours
> later, with the drive cold, I got a
>
> Dec 8 07:34:49 adams kernel: [84890.4332
On Thu, Dec 08, 2011 at 03:19:38PM +, Jeremy Sanders wrote:
> Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
> (Fedora 16, x86_64, dual-core), where after a few hours of writing, it
> switches from writing with several threads to writing with one:
Ok, I'll try to
Hi - I'm trying out btrfs again, and I see the same old bug in kernel 3.1.4
(Fedora 16, x86_64, dual-core), where after a few hours of writing, it
switches from writing with several threads to writing with one:
After:
21996 root 20 0 000 R 97.2 0.0 109:03.57 btrfs-delalloc-
Hi folks.
Last night one of the USB attached disks malfunctioned during a
balance. I strongly suspect the drive will die soon. A couple hours
later, with the drive cold, I got a
Dec 8 07:34:49 adams kernel: [84890.433235] device label quatrocentao
devid 1 transid 1659 /dev/sde1
Dec 8 07:34:49 a
2011-12-07, 12:35(-06), BJ Quinn:
> I've got a 6TB btrfs array (two 3TB drives in a RAID 0). It's
> about 2/3 full and has lots of snapshots. I've written a
> script that runs through the snapshots and copies the data
> efficiently (rsync --inplace --no-whole-file) from the main
> 6TB array to a ba
30 matches
Mail list logo
