In regard to: Re: [Networker] NSR76 SP4 & Optimized disk reading ..., joe...:

I was looking on the internet, I thought the feature is NSR_READ_SIZE
described in (
http://nsrd.moab.be/2012/07/07/networker-7-6-sp4-is-generally-available/#1).

Joe-

I thought that the env var that Terry quoted looked a little odd, but
it was one of our other admins that set it and did the testing on the
Windows client where we were having issues, so I wasn't certain.  I
checked, though, and you're correct that the env var we used was
NSR_READ_SIZE.

it's the NSR_READ_SIZE that's brand new.

The NSR_READ_SIZE controls only what size read() buffer is used on
the client when save is reading from files.  On at least Linux, you
can tell what it's using by default by attaching to the "save" process
with the "strace" command and watching what the last argument is to the
"read()" system call.  For example:

15947 open("somefile.xml", O_RDONLY|O_LARGEFILE) = 9
15947 fgetxattr(9, "system.posix_acl_access", 0x0, 0) = -1 EOPNOTSUPP 
(Operation not supported)
15947 flistxattr(9, (nil), 0)           = 0
15947 read(9, "<?xml version=\"1.0\" encoding=\"UT"..., 65536) = 65536

In that case, I used

        strace -f -o /tmp/save.out -p 15947

to attach to the "save" command (the pid was 15947) and watch what it
was doing.  As you can see from the read, it used a 64K read size.

When our Windows experts were testing NSR_READ_SIZE, I think they used
something called Xperf to see what size it was using for the read.

As I said in an earlier post, in our experience, the auto-tuned algorithm
still wasn't aggressive enough in setting the block size, which is why
we even experimented with overriding it.

For very simple volumes (for example a Linux ext3 filesystem on top of a
partition on a single disk), it's going to make less of a difference than
for more complicated storage stacks (ext3 or ext4 on top of LVM on top of
Linux software RAID1 on top of a pair of geographically separated RAID5
volumes).  If you know what the optimum read size is for your storage
stack, forcing NSR_READ_SIZE to be the same size should give you optimum
read performance.

On a side note?  Would NSR_DEV_BLOCK_SIZE work if I was writing to
DataDomain?    I have some large databases that I am backing up that might
improve with a larger BLOCK_SIZE.

I think someone else has partly answered that, though I no longer have
the reply to quote.

If I understand what you're asking, you're wondering if you might get
better throughput when writing to your Data Domain if you forced the
NetWorker server to use a larger write block size.  While that's
potentially true with traditional backup devices (e.g. tape devices),
I have no idea how or if that would work when the backup device is
Data Domain.  I'm certain that there *is* an optimum write size, but
I don't know what it would be and I would be seriously hesitant about
trying to force something there.

NSR_DEV_BLOCK_SIZE really exists for the case where you're using a backup
device that NetWorker doesn't officially support (yet), so it doesn't
know what it should be using for write/read size with that device. The
env var allows you to set an appropriate size for that device.  For
example, if you wanted to use LTO6 with NetWorker before it was
officially supported and it was the case that LTO6 was optimized for
a block size that was twice what LTO5 used, you could use the environment
variable to set it to the appropriate size.

In theory, NSR_DEV_BLOCK_SIZE might also be useful with a file type device
or AFTD, if the device was on top of a storage system like a RAID 5 volume
where you have an optimum write/read size.  Especially for writes, with
something like RAID5 you want to avoid writes that trigger a
read-modify-write penalty.

Hope this helps,

Tim
--
Tim Mooney                                             Tim.Mooney AT ndsu DOT 
edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164