xfsdump INTERRUPT issue

xfsdump INTERRUPT issue

[J. Ellis]

[-- Attachment #1.1: Type: text/plain, Size: 997 bytes --]

I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm
getting, and I'm trying to follow the guidelines for reporting such issues
here:

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_r
eporting_a_problem.3F

But these last two instructions I'm having a problem finding the information
on how to generate:


xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc,
but it keeps saying for each drive that it's not a mounted xfs system IIRC)

dmesg output showing all error messages and stack traces

Then you need to describe your workload that is causing the problem, and a
demonstration of the bad behavior that is occurring. If it is a performance
problem, then 30s - 1 minute samples of:
    1.    iostat -x -d -m 5
    2.    vmstat 5


Do I run this simultaneously while xfstools are working? I'm also not sure
what's meant by describe your workload. Can someone step me through this?

Please excuse my n00bness.

Best,
Jeffrey

[-- Attachment #1.2: Type: text/html, Size: 1699 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]

Anyone?

Or do I have enough to ask the question?

Best,
J. 

On Dec 1, 2012, at 11:03 AM, "J. Ellis" <jellis@dhnet.us> wrote:

> I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm getting, and I'm trying to follow the guidelines for reporting such issues here:
> 
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> 
> But these last two instructions I'm having a problem finding the information on how to generate:
> 
> 
> xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc, but it keeps saying for each drive that it's not a mounted xfs system IIRC)
> 
> dmesg output showing all error messages and stack traces
> 
> Then you need to describe your workload that is causing the problem, and a demonstration of the bad behavior that is occurring. If it is a performance problem, then 30s - 1 minute samples of:
>     1.    iostat -x -d -m 5
>     2.    vmstat 5
> 
> 
> Do I run this simultaneously while xfstools are working? I'm also not sure what's meant by describe your workload. Can someone step me through this?
> 
> Please excuse my n00bness. 
> 
> Best,
> Jeffrey
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

[-- Attachment #1.2: Type: text/html, Size: 2365 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/1/2012 11:39 AM, Jeffrey Ellis wrote:
> Anyone?
> 
> Or do I have enough to ask the question?

We aren't the US Govt, i.e. we're not going to ignore your help request
just because you're missing a few details.  They may not be relevant
anyway.  So ask away with the details you do have.  If anything else is
needed we'll ask you to provide it.

-- 
Stan


> Best,
> J. 
> 
> On Dec 1, 2012, at 11:03 AM, "J. Ellis" <jellis@dhnet.us> wrote:
> 
>> I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm getting, and I'm trying to follow the guidelines for reporting such issues here:
>>
>> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
>>
>> But these last two instructions I'm having a problem finding the information on how to generate:
>>
>>
>> xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc, but it keeps saying for each drive that it's not a mounted xfs system IIRC)
>>
>> dmesg output showing all error messages and stack traces
>>
>> Then you need to describe your workload that is causing the problem, and a demonstration of the bad behavior that is occurring. If it is a performance problem, then 30s - 1 minute samples of:
>>     1.    iostat -x -d -m 5
>>     2.    vmstat 5
>>
>>
>> Do I run this simultaneously while xfstools are working? I'm also not sure what's meant by describe your workload. Can someone step me through this?
>>
>> Please excuse my n00bness. 
>>
>> Best,
>> Jeffrey
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
> 
> 
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Sat, Dec 01, 2012 at 11:03:57AM -0500, J. Ellis wrote:
> I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm
> getting, and I'm trying to follow the guidelines for reporting such issues
> here:
> 
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_r
> eporting_a_problem.3F
> 
> But these last two instructions I'm having a problem finding the information
> on how to generate:
> 
> 
> xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc,
> but it keeps saying for each drive that it's not a mounted xfs system IIRC)

$ man xfs_info
....
	xfs_info [ -t mtab ] mount-point
....

> dmesg output showing all error messages and stack traces

Run the dmesg command....

> Then you need to describe your workload that is causing the problem, and a
> demonstration of the bad behavior that is occurring. If it is a performance
> problem, then 30s - 1 minute samples of:
>     1.    iostat -x -d -m 5
>     2.    vmstat 5
> 
> 
> Do I run this simultaneously while xfstools are working? I'm also not sure
> what's meant by describe your workload. Can someone step me through this?

Do you have a performance problem? I don't think you have - your problem is
that xfsdump is failing for some reason - so this information is
unnecessary.

As to your workload, your problem is xfsdump is failing for some
reason. Hence we need to know roughly what xfsdump is running on.
i.e. describe the directory structure/filesystem contents being
backed up....

BTW, don't expect responses to questions in a hour late on friday
night/weekends - if you are lucky someone will be in front of their
computer over a weekend, sometimes you are not so lucky...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

Ah :)

Ok, I'll skip dmesg and add xfs_info. And I'll make sure to post everything Monday. 

Thanks again :)

Best,
J. 

On Dec 2, 2012, at 4:10 PM, Dave Chinner <david@fromorbit.com> wrote:

> On Sat, Dec 01, 2012 at 11:03:57AM -0500, J. Ellis wrote:
>> I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm
>> getting, and I'm trying to follow the guidelines for reporting such issues
>> here:
>> 
>> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_r
>> eporting_a_problem.3F
>> 
>> But these last two instructions I'm having a problem finding the information
>> on how to generate:
>> 
>> 
>> xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc,
>> but it keeps saying for each drive that it's not a mounted xfs system IIRC)
> 
> $ man xfs_info
> ....
>    xfs_info [ -t mtab ] mount-point
> ....
> 
>> dmesg output showing all error messages and stack traces
> 
> Run the dmesg command....
> 
>> Then you need to describe your workload that is causing the problem, and a
>> demonstration of the bad behavior that is occurring. If it is a performance
>> problem, then 30s - 1 minute samples of:
>>    1.    iostat -x -d -m 5
>>    2.    vmstat 5
>> 
>> 
>> Do I run this simultaneously while xfstools are working? I'm also not sure
>> what's meant by describe your workload. Can someone step me through this?
> 
> Do you have a performance problem? I don't think you have - your problem is
> that xfsdump is failing for some reason - so this information is
> unnecessary.
> 
> As to your workload, your problem is xfsdump is failing for some
> reason. Hence we need to know roughly what xfsdump is running on.
> i.e. describe the directory structure/filesystem contents being
> backed up....
> 
> BTW, don't expect responses to questions in a hour late on friday
> night/weekends - if you are lucky someone will be in front of their
> computer over a weekend, sometimes you are not so lucky...
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[J. Ellis]

Thank you to Stan and Dave for helping me through this.

Ok, here's the file, printed below.

Basically, I'm running the following commands under Ubuntu 12.10:

Type mkdir /mnt/fp
Type mkdir /mnt/hr20
Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp
Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20
Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp

When run, I get this as my output:

xfsdump: WARNING: write to stdio failed: 32 (Broken pipe)
xfsdump: ending media file
xfsdump: media file size 18874368 bytes
xfsdump: dump size (non-dir files) : 13698056 bytes
xfsdump: NOTE: dump interrupted: 16 seconds elapsed
xfsdump: Dump Status: INTERRUPT

This happens each time. In the forum where this copy procedure was
suggested, they've been reporting that the latest xfsprogs is creating these
errors, which didn't happen under at least somewhat earlier versions.

The version of xfsprogs should be in the file, but it was just downloaded a
few days ago using git.

Best,
Jeffrey



xfs requested data file:


kernel version: Linux jeffrey 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19
10:27:31 UTC 2012 i686 i686 i686 GNU/Linux

xfsprogs version: xfs_repair version 3.1.8

number of CPU's: 8

contents of /proc/meminfo:
MemTotal:        6184324 kB
MemFree:         4986560 kB
Buffers:           32036 kB
Cached:           446368 kB
SwapCached:            0 kB
Active:           680296 kB
Inactive:         402548 kB
Active(anon):     612444 kB
Inactive(anon):      368 kB
Active(file):      67852 kB
Inactive(file):   402180 kB
Unevictable:       32596 kB
Mlocked:           32596 kB
HighTotal:       5365768 kB
HighFree:        4264648 kB
LowTotal:         818556 kB
LowFree:          721912 kB
SwapTotal:       1023996 kB
SwapFree:        1023996 kB
Dirty:              1484 kB
Writeback:             0 kB
AnonPages:        637224 kB
Mapped:           148540 kB
Shmem:              1284 kB
Slab:              36908 kB
SReclaimable:      16864 kB
SUnreclaim:        20044 kB
KernelStack:        3664 kB
PageTables:         8296 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4116156 kB
Committed_AS:    3172256 kB
VmallocTotal:     122880 kB
VmallocUsed:       13156 kB
VmallocChunk:     104244 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8184 kB
DirectMap2M:      905216 kB

contents of /proc/mounts:
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=3084428k,nr_inodes=200772,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
0 0 
tmpfs /run tmpfs rw,nosuid,relatime,size=1236868k,mode=755 0 0
/dev/disk/by-uuid/e33b147d-faaa-4e55-8f3b-2fb2d3168053 / ext4
rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0
0 
gvfsd-fuse /run/user/jeffrey/gvfs fuse.gvfsd-fuse
rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

contents of /proc/partitions:
major minor  #blocks  name

  11        0    1048575 sr0
   8        0 1953514584 sda
   8        1     530113 sda1
   8        2   15735664 sda2
   8        3 1937246216 sda3
   8       16  488386584 sdb
   8       17     530113 sdb1
   8       18   15735664 sdb2
   8       19  472118216 sdb3
   8       32 1953514584 sdc
   8       33    1024000 sdc1
   8       34 1952489258 sdc2
  11        1    1048575 sr1

RAID Layout: no Raid

LVM Configuration: Sorry, I didn't have the education to get this
information.

Type of discs: 2 3.5² SATA drives, 1 half-height SATA.

hdparm results:

/dev/sda: 

ATA device, with non-removable media
    Model Number:       Hitachi HDS723020BLA642
    Serial Number:      MN1240FA04NWHD
    Firmware Revision:  MN6OA800
    Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards: 
    Used: unknown (minor revision code 0x0029)
    Supported: 8 7 6 5
    Likely used: 8 
Configuration: 
    Logical        max    current
    cylinders    16383    16383
    heads        16    16
    sectors/track    63    63
    -- 
    CHS current addressable sectors:   16514064
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors: 3907029168
    Logical  Sector size:                   512 bytes
    Physical Sector size:                   512 bytes
    device size with M = 1024*1024:     1907729 MBytes
    device size with M = 1000*1000:     2000398 MBytes (2000 GB)
    cache/buffer size  = unknown
    Form Factor: 3.5 inch
    Nominal Media Rotation Rate: 7200
Capabilities: 
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, no device specific minimum
    R/W multiple sector transfer: Max = 16    Current = 0
    Advanced power management level: disabled
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features: 
    Enabled    Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
       *    Write cache
       *    Look-ahead
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    NOP cmd
       *    DOWNLOAD_MICROCODE
            Advanced Power Management feature set
            Power-Up In Standby feature set
       *    SET_FEATURES required to spinup after power up
       *    SET_MAX security extension
       *    48-bit Address feature set
       *    Device Configuration Overlay feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
            Media Card Pass-Through
       *    General Purpose Logging feature set
       *    WRITE_{DMA|MULTIPLE}_FUA_EXT
       *    64-bit World wide name
       *    URG for READ_STREAM[_DMA]_EXT
       *    URG for WRITE_STREAM[_DMA]_EXT
       *    WRITE_UNCORRECTABLE_EXT command
       *    {READ,WRITE}_DMA_EXT_GPL commands
       *    Segmented DOWNLOAD_MICROCODE
            unknown 119[7]
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Host-initiated interface power management
       *    Phy event counters
       *    NCQ priority information
            Non-Zero buffer offsets in DMA Setup FIS
            DMA Setup Auto-Activate optimization
            Device-initiated interface power management
            In-order data delivery
       *    Software settings preservation
       *    SMART Command Transport (SCT) feature set
       *    SCT LBA Segment Access (AC2)
       *    SCT Error Recovery Control (AC3)
       *    SCT Features Control (AC4)
       *    SCT Data Tables (AC5)
Security: 
    Master password revision code = 65534
        supported 
    not    enabled 
    not    locked 
        frozen 
    not    expired: security count
    not    supported: enhanced erase
    420min for SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000cca36ac21fe4
    NAA        : 5 
    IEEE OUI    : 000cca
    Unique ID    : 36ac21fe4
Checksum: correct 


/dev/sdb: 

ATA device, with non-removable media
    Model Number:       ST3500312CS
    Serial Number:      6VV60HXR
    Firmware Revision:  SC13
    Transport:          Serial
Standards: 
    Used: unknown (minor revision code 0x0029)
    Supported: 8 7 6 5
    Likely used: 8 
Configuration: 
    Logical        max    current
    cylinders    16383    16383
    heads        16    16
    sectors/track    63    63
    -- 
    CHS current addressable sectors:   16514064
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors:  976773168
    Logical/Physical Sector size:           512 bytes
    device size with M = 1024*1024:      476940 MBytes
    device size with M = 1000*1000:      500107 MBytes (500 GB)
    cache/buffer size  = 8192 KBytes
    Nominal Media Rotation Rate: 5900
Capabilities: 
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, no device specific minimum
    R/W multiple sector transfer: Max = 16    Current = ?
    Advanced power management level: 254
    Recommended acoustic management value: 254, current value: 0
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features: 
    Enabled    Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
       *    Write cache
       *    Look-ahead
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    DOWNLOAD_MICROCODE
       *    Advanced Power Management feature set
            Power-Up In Standby feature set
            SET_FEATURES required to spinup after power up
       *    SET_MAX security extension
       *    48-bit Address feature set
       *    Device Configuration Overlay feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
       *    Media Card Pass-Through
       *    General Purpose Logging feature set
       *    64-bit World wide name
            Write-Read-Verify feature set
       *    WRITE_UNCORRECTABLE_EXT command
       *    {READ,WRITE}_DMA_EXT_GPL commands
       *    Segmented DOWNLOAD_MICROCODE
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Phy event counters
            Device-initiated interface power management
       *    Software settings preservation
       *    SMART Command Transport (SCT) feature set
       *    SCT Long Sector Access (AC1)
       *    SCT Error Recovery Control (AC3)
       *    SCT Features Control (AC4)
       *    SCT Data Tables (AC5)
            unknown 206[12] (vendor specific)
Security: 
    Master password revision code = 65534
        supported 
    not    enabled 
    not    locked 
        frozen 
    not    expired: security count
        supported: enhanced erase
    100min for SECURITY ERASE UNIT. 100min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c500307c5d66
    NAA        : 5 
    IEEE OUI    : 000c50
    Unique ID    : 0307c5d66
Checksum: correct 


/dev/sdc: 

ATA device, with non-removable media
    Model Number:       Hitachi HDS723020BLA642
    Serial Number:      MN3220F32KR53E
    Firmware Revision:  MN6OA800
    Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards: 
    Used: unknown (minor revision code 0x0029)
    Supported: 8 7 6 5
    Likely used: 8 
Configuration: 
    Logical        max    current
    cylinders    16383    16383
    heads        16    16
    sectors/track    63    63
    -- 
    CHS current addressable sectors:   16514064
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors: 3907029168
    Logical  Sector size:                   512 bytes
    Physical Sector size:                   512 bytes
    device size with M = 1024*1024:     1907729 MBytes
    device size with M = 1000*1000:     2000398 MBytes (2000 GB)
    cache/buffer size  = unknown
    Form Factor: 3.5 inch
    Nominal Media Rotation Rate: 7200
Capabilities: 
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, no device specific minimum
    R/W multiple sector transfer: Max = 16    Current = 0
    Advanced power management level: disabled
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features: 
    Enabled    Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
       *    Write cache
       *    Look-ahead
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    NOP cmd
       *    DOWNLOAD_MICROCODE
            Advanced Power Management feature set
            Power-Up In Standby feature set
       *    SET_FEATURES required to spinup after power up
       *    SET_MAX security extension
       *    48-bit Address feature set
       *    Device Configuration Overlay feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
            Media Card Pass-Through
       *    General Purpose Logging feature set
       *    WRITE_{DMA|MULTIPLE}_FUA_EXT
       *    64-bit World wide name
       *    URG for READ_STREAM[_DMA]_EXT
       *    URG for WRITE_STREAM[_DMA]_EXT
       *    WRITE_UNCORRECTABLE_EXT command
       *    {READ,WRITE}_DMA_EXT_GPL commands
       *    Segmented DOWNLOAD_MICROCODE
            unknown 119[7]
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Host-initiated interface power management
       *    Phy event counters
       *    NCQ priority information
            Non-Zero buffer offsets in DMA Setup FIS
            DMA Setup Auto-Activate optimization
            Device-initiated interface power management
            In-order data delivery
       *    Software settings preservation
       *    SMART Command Transport (SCT) feature set
       *    SCT LBA Segment Access (AC2)
       *    SCT Error Recovery Control (AC3)
       *    SCT Features Control (AC4)
       *    SCT Data Tables (AC5)
Security: 
    Master password revision code = 65534
        supported 
    not    enabled 
    not    locked 
        frozen 
    not    expired: security count
    not    supported: enhanced erase
    456min for SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000cca369e43c85
    NAA        : 5 
    IEEE OUI    : 000cca
    Unique ID    : 369e43c85
Checksum: correct 

Size of BBWC and Mode: Again, sorry, I couldn't find how to get this.

xfs_info:

root@jeffrey:~# xfs_info /mnt/fp
meta-data=/dev/sda2              isize=256    agcount=16, agsize=245869 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=3933904, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =external               extsz=1048576 blocks=484311554,
rtextents=1891842


root@jeffrey:~# xfs_info /mnt/hr20
meta-data=/dev/sdb2              isize=256    agcount=16, agsize=245869 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=3933904, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =external               extsz=1048576 blocks=118029554,
rtextents=461052







_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Mon, Dec 03, 2012 at 11:49:46AM -0500, J. Ellis wrote:
> Thank you to Stan and Dave for helping me through this.
> 
> Ok, here's the file, printed below.
> 
> Basically, I'm running the following commands under Ubuntu 12.10:
> 
> Type mkdir /mnt/fp
> Type mkdir /mnt/hr20
> Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp
> Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20
> Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp
> 
> When run, I get this as my output:
> 
> xfsdump: WARNING: write to stdio failed: 32 (Broken pipe)

FWIW, this implies that xfsrestore failed. What is the output from
xfsrestore? Can you just run xfsdump to a file?

Also, the dmesg output is missing - can you attach it?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

Hi, Dave--

> FWIW, this implies that xfsrestore failed. What is the output from
> xfsrestore? Can you just run xfsdump to a file?

Can you tell me how to do that and dmesg?

Best,
J. 

On Dec 3, 2012, at 4:34 PM, Dave Chinner <david@fromorbit.com> wrote:

> On Mon, Dec 03, 2012 at 11:49:46AM -0500, J. Ellis wrote:
>> Thank you to Stan and Dave for helping me through this.
>> 
>> Ok, here's the file, printed below.
>> 
>> Basically, I'm running the following commands under Ubuntu 12.10:
>> 
>> Type mkdir /mnt/fp
>> Type mkdir /mnt/hr20
>> Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp
>> Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20
>> Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp
>> 
>> When run, I get this as my output:
>> 
>> xfsdump: WARNING: write to stdio failed: 32 (Broken pipe)
> 
> FWIW, this implies that xfsrestore failed. What is the output from
> xfsrestore? Can you just run xfsdump to a file?
> 
> Also, the dmesg output is missing - can you attach it?
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[J. Ellis]

Hi, Dave & Stan, et al--

Are you guys getting this post? I don't see it showing up on the list and
have had no responses. I'm wondering if the size of the text of the
requested xfs info I had added is causing an issue getting it posted.

If not, here's a repost, using a link to the file instead.

http://dhnet.us/xfs/xfs_data_file.odt

Best,
Jeffrey


on 12/3/12 11:49 AM, Jeffrey Ellis at jellis@dhnet.us wrote:

> Thank you to Stan and Dave for helping me through this.
> 
> Ok, here's the file, printed below.
> 
> Basically, I'm running the following commands under Ubuntu 12.10:
> 
> Type mkdir /mnt/fp
> Type mkdir /mnt/hr20
> Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp
> Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20
> Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp
> 
> When run, I get this as my output:
> 
> xfsdump: WARNING: write to stdio failed: 32 (Broken pipe)
> xfsdump: ending media file
> xfsdump: media file size 18874368 bytes
> xfsdump: dump size (non-dir files) : 13698056 bytes
> xfsdump: NOTE: dump interrupted: 16 seconds elapsed
> xfsdump: Dump Status: INTERRUPT
> 
> This happens each time. In the forum where this copy procedure was
> suggested, they've been reporting that the latest xfsprogs is creating these
> errors, which didn't happen under at least somewhat earlier versions.
> 
> The version of xfsprogs should be in the file, but it was just downloaded a
> few days ago using git.
> 
> Best,
> Jeffrey


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/4/2012 1:46 PM, J. Ellis wrote:
> Hi, Dave & Stan, et al--
> 
> Are you guys getting this post? I don't see it showing up on the list and
> have had no responses. I'm wondering if the size of the text of the
> requested xfs info I had added is causing an issue getting it posted.

You need to acclimate yourself to the environment/culture of FLOSS
mailing lists.  First, don't be giddy.  Responses to users will rarely
be immediate.  People, both devs and fellow users, contribute help on an
"as time permits" basis.  You are not paying for support here.  I've
seen some msgs go unanswered for a week or more, both initial requests
and follow ups.  I short, don't expect rapid responses and individual
hand holding.

> If not, here's a repost, using a link to the file instead.
> 
> http://dhnet.us/xfs/xfs_data_file.odt

Regarding what you think may be lost mail, using an office document
format is not wise, though I don't know if it's allowed here or not.  In
general, with FLOSS lists, use plain text, always, whether inline or
attachment.  Try not to reference external links as this list is
archived by many sites.  Get it all in the archives.

Finally, if you sent me a direct email and my server rejected it you
would receive an NDR pretty quickly.  And I don't see any msgs from you
in my spam tagged folder.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

Hi, Stan--  

Ah, sorry. 

I actually tried sending it to you, Dave and the list by attachment and by including the text in the email. So it looks like this is the only way it got through. Should I try reposting a version with just the text again?

Best,
J. 

On Dec 4, 2012, at 5:56 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:

> On 12/4/2012 1:46 PM, J. Ellis wrote:
>> Hi, Dave & Stan, et al--
>> 
>> Are you guys getting this post? I don't see it showing up on the list and
>> have had no responses. I'm wondering if the size of the text of the
>> requested xfs info I had added is causing an issue getting it posted.
> 
> You need to acclimate yourself to the environment/culture of FLOSS
> mailing lists.  First, don't be giddy.  Responses to users will rarely
> be immediate.  People, both devs and fellow users, contribute help on an
> "as time permits" basis.  You are not paying for support here.  I've
> seen some msgs go unanswered for a week or more, both initial requests
> and follow ups.  I short, don't expect rapid responses and individual
> hand holding.
> 
>> If not, here's a repost, using a link to the file instead.
>> 
>> http://dhnet.us/xfs/xfs_data_file.odt
> 
> Regarding what you think may be lost mail, using an office document
> format is not wise, though I don't know if it's allowed here or not.  In
> general, with FLOSS lists, use plain text, always, whether inline or
> attachment.  Try not to reference external links as this list is
> archived by many sites.  Get it all in the archives.
> 
> Finally, if you sent me a direct email and my server rejected it you
> would receive an NDR pretty quickly.  And I don't see any msgs from you
> in my spam tagged folder.
> 
> -- 
> Stan
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/3/2012 4:27 PM, Jeffrey Ellis wrote:

xfs_info output and this below is all that is needed at this point.

>> FWIW, this implies that xfsrestore failed. What is the output from
>> xfsrestore? Can you just run xfsdump to a file?

> Can you tell me how to do that and dmesg?

The command you posted

xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp

pipes the output from xfsdump into xfsrestore.  This error

xfsdump: WARNING: write to stdio failed: 32 (Broken pipe)

tells us something broke while piping into xfsrestore, possibly
xfsrestore itself.  I believe what Dave is asking you is to xfsdump to a
file, then xfsrestore that file.  In two separate operations.  This
should tell us more about where the problem is.

Regarding dmesg information, simply do

~$ dmesg

and copy the output into your email.  It should be a few screen fulls
starting with something like:

Linux version 3.2.6 (root@greer) (gcc version 4.4.5 (Debian 4.4.5-8) )
#1 SMP Mon Feb 20 17:05:10 CST 2012

WRT xfs_info:

~$ cat /etc/mtab
...
/dev/sda6 /home xfs rw 0 0
...

~$ xfs_info /dev/sda6
meta-data=/dev/sda6         isize=256    agcount=4, agsize=6103694 blks
         =                  sectsz=512   attr=2
data     =                  bsize=4096   blocks=24414775, imaxpct=25
         =                  sunit=0      swidth=0 blks
naming   =version 2         bsize=4096   ascii-ci=0
log      =internal          bsize=4096   blocks=11921, version=2
         =                  sectsz=512   sunit=0 blks, lazy-count=0
realtime =none              extsz=4096   blocks=0, rtextents=0


-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[J. Ellis]

Hi, Stan--

Ok, I truly apologize for my ignorance, but I don't know how to dump the
contents to a file. Is it something like:

xfsdump -J - somefile_xfsdump.txt
xfsrestore -J - somefile_xfsrestore.txt

?

Best,
J. 


on 12/4/12 7:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote:

> On 12/3/2012 4:27 PM, Jeffrey Ellis wrote:
> 
> xfs_info output and this below is all that is needed at this point.
> 
>>> FWIW, this implies that xfsrestore failed. What is the output from
>>> xfsrestore? Can you just run xfsdump to a file?
> 
>> Can you tell me how to do that and dmesg?
> 
> The command you posted
> 
> xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp
> 
> pipes the output from xfsdump into xfsrestore.  This error
> 
> xfsdump: WARNING: write to stdio failed: 32 (Broken pipe)
> 
> tells us something broke while piping into xfsrestore, possibly
> xfsrestore itself.  I believe what Dave is asking you is to xfsdump to a
> file, then xfsrestore that file.  In two separate operations.  This
> should tell us more about where the problem is.
> 
> Regarding dmesg information, simply do
> 
> ~$ dmesg
> 
> and copy the output into your email.  It should be a few screen fulls
> starting with something like:
> 
> Linux version 3.2.6 (root@greer) (gcc version 4.4.5 (Debian 4.4.5-8) )
> #1 SMP Mon Feb 20 17:05:10 CST 2012
> 
> WRT xfs_info:
> 
> ~$ cat /etc/mtab
> ...
> /dev/sda6 /home xfs rw 0 0
> ...
> 
> ~$ xfs_info /dev/sda6
> meta-data=/dev/sda6         isize=256    agcount=4, agsize=6103694 blks
>          =                  sectsz=512   attr=2
> data     =                  bsize=4096   blocks=24414775, imaxpct=25
>          =                  sunit=0      swidth=0 blks
> naming   =version 2         bsize=4096   ascii-ci=0
> log      =internal          bsize=4096   blocks=11921, version=2
>          =                  sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none              extsz=4096   blocks=0, rtextents=0
> 


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/4/2012 7:18 PM, J. Ellis wrote:
> Hi, Stan--
> 
> Ok, I truly apologize for my ignorance, but I don't know how to dump the
> contents to a file. Is it something like:
> 
> xfsdump -J - somefile_xfsdump.txt

~$ man xfsdump

Look at option "-f".

> xfsrestore -J - somefile_xfsrestore.txt

~$ man xfsrestore

See options "-f" "-t" and "-v".

The point of this exercise I believe is to see what errors are thrown by
xfsdump or xfsrestore when they are executed independently, vs through a
pipe.  Do note that this may not be the final step in testing before you
have an answer.  Post any errors or informational output that results
from these commands.

Note that the file written by xfsdump is going to be about the same size
as the filesystem being dumped.  I.e. if the filesystem being dumped is
1TB then you need 1TB of free space on the device where the target
directory resides--you're dumping an entire XFS filesystem into a single
file.  Also, be sure to use "-t" so xfsrestore doesn't actually write
anything.  Did you read "-v"?

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Tue, Dec 04, 2012 at 06:07:38PM -0500, Jeffrey Ellis wrote:
> Hi, Stan--  
> 
> Ah, sorry. 
> 
> I actually tried sending it to you, Dave and the list by
> attachment and by including the text in the email. So it looks
> like this is the only way it got through. Should I try reposting a
> version with just the text again?

No, please don't. Everything you have sent has got through.

If you really, want to know if something got through to the list, go
an look at the list archives on one of the many list archive sites
availble. e.g. here's the entire thread:

http://marc.info/?t=135437797000003&r=1&w=2

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/5/2012 1:07 PM, J. Ellis wrote:

This should never have gone off list so I'm copying back.  If you'd have
kept this on list you'd have likely already had an answer to this.
Going off list for fear of looking ignorant is not a valid reason to do
so.  In fact there are very few reasons to ever go off list.  All it
does is take people out of the loop who are watching the thread and may
be willing to jump in at some point to help.  You've short circuited
that by going off list.

> I just read the man page again. There doesn't seem to be any examples I can
> find to write the dump to a file. I couldn't find a -t option in the man at
> all, so maybe the ones I'm finding aren't up to date. Here's the only
> example I can find, and I don't know if this would actually work:
> 
> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s
> people/fred/Source /usr

This is really simple.  Using my previous example, we want to dump to a
test file and not update the inventory.  So we have something like:

~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6

This dumps the XFS filesystem on /dev/sda6 to a file.  Don't write the
dump file to the filesystem you're dumping.  Preferably the XFS you're
dumping is on one disk or array and the target file will be written to a
different disk or array.  Dumps are IO intensive.

I clearly stated the "-t" option in the context of xfsrestore:

       -t   Displays  the  contents of the dump, but does not create or
            modify any files or directories.  It may be desirable to
            set the verbosity level to silent when using this option.

This allows you to do a test run without actually writing any files
during the restore.  The goal here is to test xfsdump and xfsrestore on
your system to see where errors are cropping up.  You don't actually
want to restore the dumped filesystem at this point.

The "-v" option simply keeps the "-t" from spamming a million file names
to your console during the restore operation.

-- 
Stan


> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote:
> 
>> On 12/4/2012 7:18 PM, J. Ellis wrote:
>>> Hi, Stan--
>>>
>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the
>>> contents to a file. Is it something like:
>>>
>>> xfsdump -J - somefile_xfsdump.txt
>>
>> ~$ man xfsdump
>>
>> Look at option "-f".
>>
>>> xfsrestore -J - somefile_xfsrestore.txt
>>
>> ~$ man xfsrestore
>>
>> See options "-f" "-t" and "-v".
>>
>> The point of this exercise I believe is to see what errors are thrown by
>> xfsdump or xfsrestore when they are executed independently, vs through a
>> pipe.  Do note that this may not be the final step in testing before you
>> have an answer.  Post any errors or informational output that results
>> from these commands.
>>
>> Note that the file written by xfsdump is going to be about the same size
>> as the filesystem being dumped.  I.e. if the filesystem being dumped is
>> 1TB then you need 1TB of free space on the device where the target
>> directory resides--you're dumping an entire XFS filesystem into a single
>> file.  Also, be sure to use "-t" so xfsrestore doesn't actually write
>> anything.  Did you read "-v"?
> 
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

Hi, Stan--

You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. 

Thank you for the example. I hope I have this right. So including the -t and -v would be 

~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0

Repeat for each mount point, and post the result here?

Thanks again. 
Jeffrey

> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6



Best,
J. 

On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:

> On 12/5/2012 1:07 PM, J. Ellis wrote:
> 
> This should never have gone off list so I'm copying back.  If you'd have
> kept this on list you'd have likely already had an answer to this.
> Going off list for fear of looking ignorant is not a valid reason to do
> so.  In fact there are very few reasons to ever go off list.  All it
> does is take people out of the loop who are watching the thread and may
> be willing to jump in at some point to help.  You've short circuited
> that by going off list.
> 
>> I just read the man page again. There doesn't seem to be any examples I can
>> find to write the dump to a file. I couldn't find a -t option in the man at
>> all, so maybe the ones I'm finding aren't up to date. Here's the only
>> example I can find, and I don't know if this would actually work:
>> 
>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s
>> people/fred/Source /usr
> 
> This is really simple.  Using my previous example, we want to dump to a
> test file and not update the inventory.  So we have something like:
> 
> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
> 
> This dumps the XFS filesystem on /dev/sda6 to a file.  Don't write the
> dump file to the filesystem you're dumping.  Preferably the XFS you're
> dumping is on one disk or array and the target file will be written to a
> different disk or array.  Dumps are IO intensive.
> 
> I clearly stated the "-t" option in the context of xfsrestore:
> 
>       -t   Displays  the  contents of the dump, but does not create or
>            modify any files or directories.  It may be desirable to
>            set the verbosity level to silent when using this option.
> 
> This allows you to do a test run without actually writing any files
> during the restore.  The goal here is to test xfsdump and xfsrestore on
> your system to see where errors are cropping up.  You don't actually
> want to restore the dumped filesystem at this point.
> 
> The "-v" option simply keeps the "-t" from spamming a million file names
> to your console during the restore operation.
> 
> -- 
> Stan
> 
> 
>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote:
>> 
>>> On 12/4/2012 7:18 PM, J. Ellis wrote:
>>>> Hi, Stan--
>>>> 
>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the
>>>> contents to a file. Is it something like:
>>>> 
>>>> xfsdump -J - somefile_xfsdump.txt
>>> 
>>> ~$ man xfsdump
>>> 
>>> Look at option "-f".
>>> 
>>>> xfsrestore -J - somefile_xfsrestore.txt
>>> 
>>> ~$ man xfsrestore
>>> 
>>> See options "-f" "-t" and "-v".
>>> 
>>> The point of this exercise I believe is to see what errors are thrown by
>>> xfsdump or xfsrestore when they are executed independently, vs through a
>>> pipe.  Do note that this may not be the final step in testing before you
>>> have an answer.  Post any errors or informational output that results
>>> from these commands.
>>> 
>>> Note that the file written by xfsdump is going to be about the same size
>>> as the filesystem being dumped.  I.e. if the filesystem being dumped is
>>> 1TB then you need 1TB of free space on the device where the target
>>> directory resides--you're dumping an entire XFS filesystem into a single
>>> file.  Also, be sure to use "-t" so xfsrestore doesn't actually write
>>> anything.  Did you read "-v"?
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/5/2012 8:08 PM, Jeffrey Ellis wrote:
> Hi, Stan--
> 
> You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. 
> 
> Thank you for the example. I hope I have this right. So including the -t and -v would be 
> 
> ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0

No.  That's not right.  I gave you concise separate instructions for
xfsdump and for xfsrestore, and you've commingled the two.

Please thoroughly and thoughtfully re-read my last email.

-- 
Stan


> Repeat for each mount point, and post the result here?
> 
> Thanks again. 
> Jeffrey
> 
>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
> 
> 
> 
> Best,
> J. 
> 
> On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> 
>> On 12/5/2012 1:07 PM, J. Ellis wrote:
>>
>> This should never have gone off list so I'm copying back.  If you'd have
>> kept this on list you'd have likely already had an answer to this.
>> Going off list for fear of looking ignorant is not a valid reason to do
>> so.  In fact there are very few reasons to ever go off list.  All it
>> does is take people out of the loop who are watching the thread and may
>> be willing to jump in at some point to help.  You've short circuited
>> that by going off list.
>>
>>> I just read the man page again. There doesn't seem to be any examples I can
>>> find to write the dump to a file. I couldn't find a -t option in the man at
>>> all, so maybe the ones I'm finding aren't up to date. Here's the only
>>> example I can find, and I don't know if this would actually work:
>>>
>>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s
>>> people/fred/Source /usr
>>
>> This is really simple.  Using my previous example, we want to dump to a
>> test file and not update the inventory.  So we have something like:
>>
>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
>>
>> This dumps the XFS filesystem on /dev/sda6 to a file.  Don't write the
>> dump file to the filesystem you're dumping.  Preferably the XFS you're
>> dumping is on one disk or array and the target file will be written to a
>> different disk or array.  Dumps are IO intensive.
>>
>> I clearly stated the "-t" option in the context of xfsrestore:
>>
>>       -t   Displays  the  contents of the dump, but does not create or
>>            modify any files or directories.  It may be desirable to
>>            set the verbosity level to silent when using this option.
>>
>> This allows you to do a test run without actually writing any files
>> during the restore.  The goal here is to test xfsdump and xfsrestore on
>> your system to see where errors are cropping up.  You don't actually
>> want to restore the dumped filesystem at this point.
>>
>> The "-v" option simply keeps the "-t" from spamming a million file names
>> to your console during the restore operation.
>>
>> -- 
>> Stan
>>
>>
>>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote:
>>>
>>>> On 12/4/2012 7:18 PM, J. Ellis wrote:
>>>>> Hi, Stan--
>>>>>
>>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the
>>>>> contents to a file. Is it something like:
>>>>>
>>>>> xfsdump -J - somefile_xfsdump.txt
>>>>
>>>> ~$ man xfsdump
>>>>
>>>> Look at option "-f".
>>>>
>>>>> xfsrestore -J - somefile_xfsrestore.txt
>>>>
>>>> ~$ man xfsrestore
>>>>
>>>> See options "-f" "-t" and "-v".
>>>>
>>>> The point of this exercise I believe is to see what errors are thrown by
>>>> xfsdump or xfsrestore when they are executed independently, vs through a
>>>> pipe.  Do note that this may not be the final step in testing before you
>>>> have an answer.  Post any errors or informational output that results
>>>> from these commands.
>>>>
>>>> Note that the file written by xfsdump is going to be about the same size
>>>> as the filesystem being dumped.  I.e. if the filesystem being dumped is
>>>> 1TB then you need 1TB of free space on the device where the target
>>>> directory resides--you're dumping an entire XFS filesystem into a single
>>>> file.  Also, be sure to use "-t" so xfsrestore doesn't actually write
>>>> anything.  Did you read "-v"?
>>
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
> Ok. 
> 
> xfsdump -J -f /xfsdump_file /dev/sda6

/ isn't a suitable location to write a dump file.  Find a suitable
location on another filesystem with enough free space to hold the dump.
 "xfsdump_file" is an example file name.  Use whatever file name you wish.

My example XFS filesystem used for illustration purposes resides on
/dev/sda6 on one of my machines.  /dev/sda6 is probably not the location
of the filesystem you are dumping.  On what device does your XFS
filesystem reside?

> xfsrestore -t -v /xfsdump_file

Just forget the "-v".  It'll make things easier.

> Then I post the results?

After you get all of the above straightened out.

BTW, if your goal in all of this is simply copying all the directories
and files from one disk to another disk, you could have used "cp -a" and
been done already.  It takes longer to execute than xfsdump/xfsrestore,
but given you've been at this for many days now, "cp -a" would have
already completed--long ago.

-- 
Stan


> Best,
> J. 
> 
> On Dec 5, 2012, at 9:40 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> 
>> On 12/5/2012 8:08 PM, Jeffrey Ellis wrote:
>>> Hi, Stan--
>>>
>>> You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. 
>>>
>>> Thank you for the example. I hope I have this right. So including the -t and -v would be 
>>>
>>> ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0
>>
>> No.  That's not right.  I gave you concise separate instructions for
>> xfsdump and for xfsrestore, and you've commingled the two.
>>
>> Please thoroughly and thoughtfully re-read my last email.
>>
>> -- 
>> Stan
>>
>>
>>> Repeat for each mount point, and post the result here?
>>>
>>> Thanks again. 
>>> Jeffrey
>>>
>>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
>>>
>>>
>>>
>>> Best,
>>> J. 
>>>
>>> On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>>
>>>> On 12/5/2012 1:07 PM, J. Ellis wrote:
>>>>
>>>> This should never have gone off list so I'm copying back.  If you'd have
>>>> kept this on list you'd have likely already had an answer to this.
>>>> Going off list for fear of looking ignorant is not a valid reason to do
>>>> so.  In fact there are very few reasons to ever go off list.  All it
>>>> does is take people out of the loop who are watching the thread and may
>>>> be willing to jump in at some point to help.  You've short circuited
>>>> that by going off list.
>>>>
>>>>> I just read the man page again. There doesn't seem to be any examples I can
>>>>> find to write the dump to a file. I couldn't find a -t option in the man at
>>>>> all, so maybe the ones I'm finding aren't up to date. Here's the only
>>>>> example I can find, and I don't know if this would actually work:
>>>>>
>>>>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s
>>>>> people/fred/Source /usr
>>>>
>>>> This is really simple.  Using my previous example, we want to dump to a
>>>> test file and not update the inventory.  So we have something like:
>>>>
>>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
>>>>
>>>> This dumps the XFS filesystem on /dev/sda6 to a file.  Don't write the
>>>> dump file to the filesystem you're dumping.  Preferably the XFS you're
>>>> dumping is on one disk or array and the target file will be written to a
>>>> different disk or array.  Dumps are IO intensive.
>>>>
>>>> I clearly stated the "-t" option in the context of xfsrestore:
>>>>
>>>>      -t   Displays  the  contents of the dump, but does not create or
>>>>           modify any files or directories.  It may be desirable to
>>>>           set the verbosity level to silent when using this option.
>>>>
>>>> This allows you to do a test run without actually writing any files
>>>> during the restore.  The goal here is to test xfsdump and xfsrestore on
>>>> your system to see where errors are cropping up.  You don't actually
>>>> want to restore the dumped filesystem at this point.
>>>>
>>>> The "-v" option simply keeps the "-t" from spamming a million file names
>>>> to your console during the restore operation.
>>>>
>>>> -- 
>>>> Stan
>>>>
>>>>
>>>>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote:
>>>>>
>>>>>> On 12/4/2012 7:18 PM, J. Ellis wrote:
>>>>>>> Hi, Stan--
>>>>>>>
>>>>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the
>>>>>>> contents to a file. Is it something like:
>>>>>>>
>>>>>>> xfsdump -J - somefile_xfsdump.txt
>>>>>>
>>>>>> ~$ man xfsdump
>>>>>>
>>>>>> Look at option "-f".
>>>>>>
>>>>>>> xfsrestore -J - somefile_xfsrestore.txt
>>>>>>
>>>>>> ~$ man xfsrestore
>>>>>>
>>>>>> See options "-f" "-t" and "-v".
>>>>>>
>>>>>> The point of this exercise I believe is to see what errors are thrown by
>>>>>> xfsdump or xfsrestore when they are executed independently, vs through a
>>>>>> pipe.  Do note that this may not be the final step in testing before you
>>>>>> have an answer.  Post any errors or informational output that results
>>>>>> from these commands.
>>>>>>
>>>>>> Note that the file written by xfsdump is going to be about the same size
>>>>>> as the filesystem being dumped.  I.e. if the filesystem being dumped is
>>>>>> 1TB then you need 1TB of free space on the device where the target
>>>>>> directory resides--you're dumping an entire XFS filesystem into a single
>>>>>> file.  Also, be sure to use "-t" so xfsrestore doesn't actually write
>>>>>> anything.  Did you read "-v"?
>>>
>>> _______________________________________________
>>> xfs mailing list
>>> xfs@oss.sgi.com
>>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

> / isn't a suitable location to write a dump file.  Find a suitable
> location on another filesystem with enough free space to hold the dump.
> "xfsdump_file" is an example file name.  Use whatever file name you wish.

That was just an example. 

> My example XFS filesystem used for illustration purposes resides on
> /dev/sda6 on one of my machines.  /dev/sda6 is probably not the location
> of the filesystem you are dumping.  On what device does your XFS
> filesystem reside?

There are two. /dev/sda0 and /dev/sdb1, IIRC. The first is a blank drive however. 

>> xfsrestore -t -v /xfsdump_file
> 
> Just forget the "-v".  It'll make things easier.

So that command is good?

> BTW, if your goal in all of this is simply copying all the directories
> and files from one disk to another disk, you could have used "cp -a" and
> been done already.  It takes longer to execute than xfsdump/xfsrestore,
> but given you've been at this for many days now, "cp -a" would have
> already completed--long ago.

No, I wish it was. 

Best,
Jeffrey

On Dec 6, 2012, at 4:29 AM, Stan Hoeppner <stan@hardwarefreak.com> wrote:

> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
>> Ok. 
>> 
>> xfsdump -J -f /xfsdump_file /dev/sda6
> 
> / isn't a suitable location to write a dump file.  Find a suitable
> location on another filesystem with enough free space to hold the dump.
> "xfsdump_file" is an example file name.  Use whatever file name you wish.
> 
> My example XFS filesystem used for illustration purposes resides on
> /dev/sda6 on one of my machines.  /dev/sda6 is probably not the location
> of the filesystem you are dumping.  On what device does your XFS
> filesystem reside?
> 
>> xfsrestore -t -v /xfsdump_file
> 
> Just forget the "-v".  It'll make things easier.
> 
>> Then I post the results?
> 
> After you get all of the above straightened out.
> 
> BTW, if your goal in all of this is simply copying all the directories
> and files from one disk to another disk, you could have used "cp -a" and
> been done already.  It takes longer to execute than xfsdump/xfsrestore,
> but given you've been at this for many days now, "cp -a" would have
> already completed--long ago.
> 
> -- 
> Stan
> 
> 
>> Best,
>> J. 
>> 
>> On Dec 5, 2012, at 9:40 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>> 
>>> On 12/5/2012 8:08 PM, Jeffrey Ellis wrote:
>>>> Hi, Stan--
>>>> 
>>>> You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. 
>>>> 
>>>> Thank you for the example. I hope I have this right. So including the -t and -v would be 
>>>> 
>>>> ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0
>>> 
>>> No.  That's not right.  I gave you concise separate instructions for
>>> xfsdump and for xfsrestore, and you've commingled the two.
>>> 
>>> Please thoroughly and thoughtfully re-read my last email.
>>> 
>>> -- 
>>> Stan
>>> 
>>> 
>>>> Repeat for each mount point, and post the result here?
>>>> 
>>>> Thanks again. 
>>>> Jeffrey
>>>> 
>>>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
>>>> 
>>>> 
>>>> 
>>>> Best,
>>>> J. 
>>>> 
>>>> On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>>> 
>>>>> On 12/5/2012 1:07 PM, J. Ellis wrote:
>>>>> 
>>>>> This should never have gone off list so I'm copying back.  If you'd have
>>>>> kept this on list you'd have likely already had an answer to this.
>>>>> Going off list for fear of looking ignorant is not a valid reason to do
>>>>> so.  In fact there are very few reasons to ever go off list.  All it
>>>>> does is take people out of the loop who are watching the thread and may
>>>>> be willing to jump in at some point to help.  You've short circuited
>>>>> that by going off list.
>>>>> 
>>>>>> I just read the man page again. There doesn't seem to be any examples I can
>>>>>> find to write the dump to a file. I couldn't find a -t option in the man at
>>>>>> all, so maybe the ones I'm finding aren't up to date. Here's the only
>>>>>> example I can find, and I don't know if this would actually work:
>>>>>> 
>>>>>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s
>>>>>> people/fred/Source /usr
>>>>> 
>>>>> This is really simple.  Using my previous example, we want to dump to a
>>>>> test file and not update the inventory.  So we have something like:
>>>>> 
>>>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6
>>>>> 
>>>>> This dumps the XFS filesystem on /dev/sda6 to a file.  Don't write the
>>>>> dump file to the filesystem you're dumping.  Preferably the XFS you're
>>>>> dumping is on one disk or array and the target file will be written to a
>>>>> different disk or array.  Dumps are IO intensive.
>>>>> 
>>>>> I clearly stated the "-t" option in the context of xfsrestore:
>>>>> 
>>>>>     -t   Displays  the  contents of the dump, but does not create or
>>>>>          modify any files or directories.  It may be desirable to
>>>>>          set the verbosity level to silent when using this option.
>>>>> 
>>>>> This allows you to do a test run without actually writing any files
>>>>> during the restore.  The goal here is to test xfsdump and xfsrestore on
>>>>> your system to see where errors are cropping up.  You don't actually
>>>>> want to restore the dumped filesystem at this point.
>>>>> 
>>>>> The "-v" option simply keeps the "-t" from spamming a million file names
>>>>> to your console during the restore operation.
>>>>> 
>>>>> -- 
>>>>> Stan
>>>>> 
>>>>> 
>>>>>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote:
>>>>>> 
>>>>>>> On 12/4/2012 7:18 PM, J. Ellis wrote:
>>>>>>>> Hi, Stan--
>>>>>>>> 
>>>>>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the
>>>>>>>> contents to a file. Is it something like:
>>>>>>>> 
>>>>>>>> xfsdump -J - somefile_xfsdump.txt
>>>>>>> 
>>>>>>> ~$ man xfsdump
>>>>>>> 
>>>>>>> Look at option "-f".
>>>>>>> 
>>>>>>>> xfsrestore -J - somefile_xfsrestore.txt
>>>>>>> 
>>>>>>> ~$ man xfsrestore
>>>>>>> 
>>>>>>> See options "-f" "-t" and "-v".
>>>>>>> 
>>>>>>> The point of this exercise I believe is to see what errors are thrown by
>>>>>>> xfsdump or xfsrestore when they are executed independently, vs through a
>>>>>>> pipe.  Do note that this may not be the final step in testing before you
>>>>>>> have an answer.  Post any errors or informational output that results
>>>>>>> from these commands.
>>>>>>> 
>>>>>>> Note that the file written by xfsdump is going to be about the same size
>>>>>>> as the filesystem being dumped.  I.e. if the filesystem being dumped is
>>>>>>> 1TB then you need 1TB of free space on the device where the target
>>>>>>> directory resides--you're dumping an entire XFS filesystem into a single
>>>>>>> file.  Also, be sure to use "-t" so xfsrestore doesn't actually write
>>>>>>> anything.  Did you read "-v"?
>>>> 
>>>> _______________________________________________
>>>> xfs mailing list
>>>> xfs@oss.sgi.com
>>>> http://oss.sgi.com/mailman/listinfo/xfs
>>> 
>>> _______________________________________________
>>> xfs mailing list
>>> xfs@oss.sgi.com
>>> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
> BTW, if your goal in all of this is simply copying all the directories
> and files from one disk to another disk, you could have used "cp -a" and
> been done already.  It takes longer to execute than xfsdump/xfsrestore,
> but given you've been at this for many days now, "cp -a" would have
> already completed--long ago.

Unfortunately, using cp or rsync is not possible because the
filesystem has a real-time device attached to it. It's basically a
~10GB data device and a ~500GB real-time device. I'd say it's from a
DVR or something like that, and that Jeffrey is trying to put
a bigger disk in the DVR....

Hence there are various DVR forums that suggest xfsdump/xfsrestore
is the best method for copying such filesystems to a larger disk.
I'd guess that people haven't found xfs_rtcp, or maybe they saw the
caveat in the man page(*) and didn't use it....

Cheers,

Dave.

(*) CAVEATS
       Currently, realtime partitions are not supported under the
       Linux version of XFS, and use of a realtime partition WILL
       CAUSE CORRUPTION on the data partition. As such, this command
       is made available for curious DEVELOPERS  ONLY at  this
       point  in time.

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

That's it exactly. You mean I could use xfs_rtcp?

Best,
J. 

On Dec 7, 2012, at 5:16 AM, Dave Chinner <david@fromorbit.com> wrote:

> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
>> BTW, if your goal in all of this is simply copying all the directories
>> and files from one disk to another disk, you could have used "cp -a" and
>> been done already.  It takes longer to execute than xfsdump/xfsrestore,
>> but given you've been at this for many days now, "cp -a" would have
>> already completed--long ago.
> 
> Unfortunately, using cp or rsync is not possible because the
> filesystem has a real-time device attached to it. It's basically a
> ~10GB data device and a ~500GB real-time device. I'd say it's from a
> DVR or something like that, and that Jeffrey is trying to put
> a bigger disk in the DVR....
> 
> Hence there are various DVR forums that suggest xfsdump/xfsrestore
> is the best method for copying such filesystems to a larger disk.
> I'd guess that people haven't found xfs_rtcp, or maybe they saw the
> caveat in the man page(*) and didn't use it....
> 
> Cheers,
> 
> Dave.
> 
> (*) CAVEATS
>       Currently, realtime partitions are not supported under the
>       Linux version of XFS, and use of a realtime partition WILL
>       CAUSE CORRUPTION on the data partition. As such, this command
>       is made available for curious DEVELOPERS  ONLY at  this
>       point  in time.
> 
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/7/2012 4:16 AM, Dave Chinner wrote:
> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
>> BTW, if your goal in all of this is simply copying all the directories
>> and files from one disk to another disk, you could have used "cp -a" and
>> been done already.  It takes longer to execute than xfsdump/xfsrestore,
>> but given you've been at this for many days now, "cp -a" would have
>> already completed--long ago.
> 
> Unfortunately, using cp or rsync is not possible because the
> filesystem has a real-time device attached to it. It's basically a
> ~10GB data device and a ~500GB real-time device. I'd say it's from a
> DVR or something like that, and that Jeffrey is trying to put
> a bigger disk in the DVR....

Ah, yes.  I didn't catch the RT volume.

Incidentally, since the real-time feature has never been fully supported
under Linux, why are DVR manufacturers even using it?  Without GRIO and
the XBOW ASIC the real-time volume is pretty much useless isn't it?

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote:
> On 12/7/2012 4:16 AM, Dave Chinner wrote:
> > On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
> >> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
> >> BTW, if your goal in all of this is simply copying all the directories
> >> and files from one disk to another disk, you could have used "cp -a" and
> >> been done already.  It takes longer to execute than xfsdump/xfsrestore,
> >> but given you've been at this for many days now, "cp -a" would have
> >> already completed--long ago.
> > 
> > Unfortunately, using cp or rsync is not possible because the
> > filesystem has a real-time device attached to it. It's basically a
> > ~10GB data device and a ~500GB real-time device. I'd say it's from a
> > DVR or something like that, and that Jeffrey is trying to put
> > a bigger disk in the DVR....
> 
> Ah, yes.  I didn't catch the RT volume.
> 
> Incidentally, since the real-time feature has never been fully supported
> under Linux, why are DVR manufacturers even using it?  Without GRIO and
> the XBOW ASIC the real-time volume is pretty much useless isn't it?

The realtime volume actually has nothing to do with "real-time" at
all. What it has is a deterministic allocator (bitmap rather than
tree based) which is what you need for real-time applications (i.e.
bound worst case performance). It got called the "real-time device"
because of the applications it was used for, not because there is
anything "real-time" about it.  IOWs, you don't need special
hardware to take advantage of the properties of the allocator.

DVR manufacturers have decided to use it for 3 reasons:

	1. Folklore says you need a RT device for
	   concurrent streaming workloads
	2. It's supported upstream
	3. It makes it hard for windows users to replace the
	   harddisk in the DVR by themselves (true).

#3 is the case we are seeing here.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Fri, Dec 07, 2012 at 11:15:30AM -0500, Jeffrey Ellis wrote:
> That's it exactly. You mean I could use xfs_rtcp?

You could, but did you read the caveat and understand what it means?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Jeffrey Ellis]

Gulp. I thought you were suggesting I might still use it in my case. 

Best,
J. 

On Dec 7, 2012, at 5:59 PM, Dave Chinner <david@fromorbit.com> wrote:

> On Fri, Dec 07, 2012 at 11:15:30AM -0500, Jeffrey Ellis wrote:
>> That's it exactly. You mean I could use xfs_rtcp?
> 
> You could, but did you read the caveat and understand what it means?
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Stan Hoeppner]

On 12/7/2012 4:58 PM, Dave Chinner wrote:
> On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote:
>> On 12/7/2012 4:16 AM, Dave Chinner wrote:
>>> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
>>>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
>>>> BTW, if your goal in all of this is simply copying all the directories
>>>> and files from one disk to another disk, you could have used "cp -a" and
>>>> been done already.  It takes longer to execute than xfsdump/xfsrestore,
>>>> but given you've been at this for many days now, "cp -a" would have
>>>> already completed--long ago.
>>>
>>> Unfortunately, using cp or rsync is not possible because the
>>> filesystem has a real-time device attached to it. It's basically a
>>> ~10GB data device and a ~500GB real-time device. I'd say it's from a
>>> DVR or something like that, and that Jeffrey is trying to put
>>> a bigger disk in the DVR....
>>
>> Ah, yes.  I didn't catch the RT volume.
>>
>> Incidentally, since the real-time feature has never been fully supported
>> under Linux, why are DVR manufacturers even using it?  Without GRIO and
>> the XBOW ASIC the real-time volume is pretty much useless isn't it?
> 
> The realtime volume actually has nothing to do with "real-time" at
> all. What it has is a deterministic allocator (bitmap rather than
> tree based) which is what you need for real-time applications (i.e.
> bound worst case performance). It got called the "real-time device"
> because of the applications it was used for, not because there is
> anything "real-time" about it.  IOWs, you don't need special
> hardware to take advantage of the properties of the allocator.
> 
> DVR manufacturers have decided to use it for 3 reasons:
> 
> 	1. Folklore says you need a RT device for
> 	   concurrent streaming workloads
> 	2. It's supported upstream

Define "support" and "upstream".  The few RT related posts over the past
years generated responses, some from you I think, that the RT code isn't
maintained, hasn't been for a long time.  Maybe I've misunderstood.

> 	3. It makes it hard for windows users to replace the
> 	   harddisk in the DVR by themselves (true).
> 
> #3 is the case we are seeing here.

Yes this seems to be the case.

> Cheers,
> 
> Dave.
> 

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump INTERRUPT issue

[Dave Chinner]

On Fri, Dec 07, 2012 at 05:26:12PM -0600, Stan Hoeppner wrote:
> On 12/7/2012 4:58 PM, Dave Chinner wrote:
> > On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote:
> >> On 12/7/2012 4:16 AM, Dave Chinner wrote:
> >>> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote:
> >>>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote:
> >>>> BTW, if your goal in all of this is simply copying all the directories
> >>>> and files from one disk to another disk, you could have used "cp -a" and
> >>>> been done already.  It takes longer to execute than xfsdump/xfsrestore,
> >>>> but given you've been at this for many days now, "cp -a" would have
> >>>> already completed--long ago.
> >>>
> >>> Unfortunately, using cp or rsync is not possible because the
> >>> filesystem has a real-time device attached to it. It's basically a
> >>> ~10GB data device and a ~500GB real-time device. I'd say it's from a
> >>> DVR or something like that, and that Jeffrey is trying to put
> >>> a bigger disk in the DVR....
> >>
> >> Ah, yes.  I didn't catch the RT volume.
> >>
> >> Incidentally, since the real-time feature has never been fully supported
> >> under Linux, why are DVR manufacturers even using it?  Without GRIO and
> >> the XBOW ASIC the real-time volume is pretty much useless isn't it?
> > 
> > The realtime volume actually has nothing to do with "real-time" at
> > all. What it has is a deterministic allocator (bitmap rather than
> > tree based) which is what you need for real-time applications (i.e.
> > bound worst case performance). It got called the "real-time device"
> > because of the applications it was used for, not because there is
> > anything "real-time" about it.  IOWs, you don't need special
> > hardware to take advantage of the properties of the allocator.
> > 
> > DVR manufacturers have decided to use it for 3 reasons:
> > 
> > 	1. Folklore says you need a RT device for
> > 	   concurrent streaming workloads
> > 	2. It's supported upstream
> 
> Define "support" and "upstream".  The few RT related posts over the past
> years generated responses, some from you I think, that the RT code isn't
> maintained, hasn't been for a long time.  Maybe I've misunderstood.

We've found that over the past few years that there have been a lot
of "silent users". While we don't actively develop/improve the RT
functionality, maintenance still takes place. That is, we take they
patches for the bugs users find and we try not to introduce new bugs
as we change stuff.  And I do run xfstests with realtime devices
every so often - it's just not a high priority.

IOWs, if a vendor wants to ship a product based on the real-time
functionality, then that is their choice. It is also their
responsibility to ensure what they ship is fit for purpose, which is
why they have their own QA.... :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs