Re: [gentoo-user] Hard drive storage questions

2018-11-10 Thread Dale
Rich Freeman wrote:
> On Thu, Nov 8, 2018 at 8:16 PM Dale  wrote:
>> I'm trying to come up with a
>> plan that allows me to grow easier and without having to worry about
>> running out of motherboard based ports.
>>
> So, this is an issue I've been changing my mind on over the years.
> There are a few common approaches:
>
> * Find ways to cram a lot of drives on one host
> * Use a patchwork of NAS devices or improvised hosts sharing over
> samba/nfs/etc and end up with a mess of mount points.
> * Use a distributed FS
>
> Right now I'm mainly using the first approach, and I'm trying to move
> to the last.  The middle option has never appealed to me.

And this is what I'm trying to avoid.  Doing one thing, realizing I
should have done it different and then having to spend even more money
to do it the right way.  I'm trying to get advice on what is the best
way forward that I can afford.  Obviously I don't need a setup like
facebook, google or something but I don't want to spend a few hundred
dollars doing something only to realize, it needs to be sold to the next
idiot on Ebay.   ROFL  You're giving me some good options to think on
here.  ;-) 

>
> So, to do more of what you're doing in the most efficient way
> possible, I recommend finding used LSI HBA cards.  These have mini-SAS
> ports on them, and one of these can be attached to a breakout cable
> that gets you 4 SATA ports.  I just picked up two of these for $20
> each on ebay (used) and they have 4 mini-SAS ports each, which is
> capacity for 16 SATA drives per card.  Typically these have 4x or
> larger PCIe interfaces, so you'll need a large slot, or one with a
> cutout.  You'd have to do the math but I suspect that if the card+MB
> supports PCIe 3.0 you're not losing much if you cram it into a smaller
> slot.  If most of the drives are idle most of the time then that also
> demands less bandwidth.  16 fully busy hard drives obviously can put
> out a lot of data if reading sequentially.
>
> You can of course get more consumer-oriented SATA cards, but you're
> lucky to get 2-4 SATA ports on a card that runs you $30.  The mini-SAS
> HBAs get you a LOT more drives per PCIe slot, and your PCIe slots are
> you main limiting factor assuming you have power and case space.
>
> Oh, and those HBA cards need to be flashed into "IT" mode - they're
> often sold this way, but if they support RAID you want to flash the IT
> firmware that just makes them into a bunch of standalone SATA slots.
> This is usually a PITA that involves DOS or whatever, but I have
> noticed some of the software needed in the Gentoo repo.
>
> If you go that route it is just like having a ton of SATA ports in
> your system - they just show up as sda...sdz and so on (no idea where
> it goes after that).  Software-wise you just keep doing what you're
> already doing (though you should be seriously considering
> mdadm/zfs/btrfs/whatever at that point).
>
> That is the more traditional route.
>
> Now let me talk about distributed filesystems, which is the more
> scalable approach.  I'm getting tired of being limited by SATA ports,
> and cases, and such.  I'm also frustrated with some of zfs's
> inflexibility around removing drives.  These are constraints that make
> upgrading painful, and often inefficient.  Distributed filesystems
> offer a different solution.
>
> A distributed filesystem spreads its storage across many hosts, with
> an arbitrary number of drives per host (more or less).  So, you can
> add more hosts, add more drives to a host, and so on.  That means
> you're never forced to try to find a way to cram a few more drives in
> one host.  The resulting filesystem appears as one gigantic filesystem
> (unless you want to split it up), which means no mess of nfs
> mountpoints and so on, and all the other headaches of nfs.  Just as
> with RAID these support redundancy, except now you can lose entire
> hosts without issue.  With many you can even tell it which
> PDU/rack/whatever each host is plugged into, and it will make sure you
> can lose all the hosts in one rack.  You can also mount the filesystem
> on as many hosts as you want at the same time.
>
> They do tend to be a bit more complex.  The big players can scale VERY
> large - thousands of drives easily.  Everything seems to be moving
> towards Ceph/CephFS.  If you were hosting a datacenter full of
> VMs/containers/etc I'd be telling you to host it on Ceph.  However,
> for small scale (which you definitely are right now), I'm not thrilled
> with it.  Due to the way it allocates data (hash-based) anytime
> anything changes you end up having to move all the data around in the
> cluster, and all the reports I've read suggests it doesn't perform all
> that great if you only have a few nodes.  Ceph storage nodes are also
> RAM-hungry, and I want to run these on ARM to save power, and few ARM
> boards have that kind of RAM, and they're very expensive.
>
> Personally I'm working on deploying a cluster of a few nodes running
> LizardFS, 

[gentoo-user] Scanners, sane and driver support question

2018-11-10 Thread Dale
Howdy,

I'm on the hunt for a scanner, flatbed type, and have been browsing Ebay
and the sane project list of supported devices.  I'm leaning toward HP
on this.  While looking at say a ScanJet 6200C, it says the drivers are
no longer maintained but complete.  It leads me to this question.  Does
that mean they are complete and fixes will no longer be made even if
something breaks them and they need a little tweaking OR they are
complete and if a bug pops up, they will be fixed as needed but all
functions work?  I can see the logic either way on this.  I'm leaning
toward the side that if something pops up that requires a little
tweaking, it will be done by someone.  The drivers are just feature
complete. 

Does anyone else have the same thinking or is buying one of these
scanners a bad idea if the drivers were to break and the scanner was
rendered no longer usable? 

Thanks.

Dale

:-)  :-) 



Re: [gentoo-user] libQt5Core.so.5 => not found

2018-11-10 Thread Alexander Kapshuk
On Fri, Nov 9, 2018 at 1:33 PM  wrote:
>
> I'm trying to build/emerge dev-qt/qtgui-5.11.1, but I get this:
>
> # ldd 
> /Net/portage_tmpdir/portage/dev-qt/qtgui-5.11.1/work/qtbase-everywhere-src-5.11.1/bin/qvkgen
> linux-vdso.so.1 (0x7fff3ddff000)
> libQt5Core.so.5 => not found
> libc.so.6 => /lib64/libc.so.6 (0x7f697dbd8000)
> /lib64/ld-linux-x86-64.so.2 (0x7f697e1f5000)
> # strings /etc/ld.so.cache | grep libQt5Core.so.5
> libQt5Core.so.5
> /usr/lib64/libQt5Core.so.5
> # ls -l /usr/lib64/libQt5Core.so.5*
> lrwxrwxrwx 1 root root  20 Nov  5 12:49 /usr/lib64/libQt5Core.so.5 -> 
> libQt5Core.so.5.11.1
> lrwxrwxrwx 1 root root  20 Nov  5 12:49 /usr/lib64/libQt5Core.so.5.11 -> 
> libQt5Core.so.5.11.1
> -rwxr-xr-x 1 root root 5351376 Nov  5 12:49 /usr/lib64/libQt5Core.so.5.11.1
>
> So why isn't it found ?
>
> Regards,
> /Karl Hammar
>
> ---
> Aspö Data
> Lilla Aspö 148
> S-742 94 Östhammar
> Sweden
>
>
>

Seeing the actual build error message, rather then the output of ldd,
may contain information about the build environment, and other
information that might offer better clues as to what else might be
amiss.
Also, the output of 'strace /bin/qvkgen' will indicate what paths are
searched for libQt5Core.so.5.



Re: [gentoo-user] libQt5Core.so.5 => not found

2018-11-10 Thread karl
David Haller:
> On Fri, 09 Nov 2018, k...@aspodata.se wrote:
> >I'm trying to build/emerge dev-qt/qtgui-5.11.1, but I get this:
> >
> ># ldd 
> >/Net/portage_tmpdir/portage/dev-qt/qtgui-5.11.1/work/qtbase-everywhere-src-5.11.1/bin/qvkgen
> >linux-vdso.so.1 (0x7fff3ddff000)
> >libQt5Core.so.5 => not found
> >libc.so.6 => /lib64/libc.so.6 (0x7f697dbd8000)
> >/lib64/ld-linux-x86-64.so.2 (0x7f697e1f5000)
...
> >So why isn't it found ?
> 
> Are you using a kernel <3.15?
> 
> Found this at :
> "Qt 5.10 uses the renameat2 system call which is only available
> since kernel 3.15."

Ok, 3.12.8 here, I'll see if an upgrade will cure it.

> The error-message of ld et.al. is rather weird and misleading though.

Yes.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden





Re: [gentoo-user] libQt5Core.so.5 => not found

2018-11-10 Thread karl
Adam Carter:
> On Sat, Nov 10, 2018 at 3:51 PM Adam Carter  wrote:
> > On Fri, Nov 9, 2018 at 10:33 PM  wrote:
> >> I'm trying to build/emerge dev-qt/qtgui-5.11.1, but I get this:
> >> # ldd
> >> /Net/portage_tmpdir/portage/dev-qt/qtgui-5.11.1/work/qtbase-everywhere-src-5.11.1/bin/qvkgen
> >> linux-vdso.so.1 (0x7fff3ddff000)
> >> libQt5Core.so.5 => not found
> >> libc.so.6 => /lib64/libc.so.6 (0x7f697dbd8000)
> >> /lib64/ld-linux-x86-64.so.2 (0x7f697e1f5000)
...
> >> So why isn't it found ?
...
> Sorry - you checked the cache. Does ldconfig -p show it?
> 
> For me;
> ldconfig -p | grep libQt5Core.so.5
> libQt5Core.so.5 (libc6,x86-64, OS ABI: Linux 3.17.0) =>
> /usr/lib64/libQt5Core.so.5

Same:

# ldconfig -p | grep libQt5Core.so.5
libQt5Core.so.5 (libc6,x86-64, OS ABI: Linux 3.17.0) => 
/usr/lib64/libQt5Core.so.5

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden





Re: [gentoo-user] libQt5Core.so.5 => not found

2018-11-10 Thread David Haller
Hello,

On Fri, 09 Nov 2018, k...@aspodata.se wrote:
>I'm trying to build/emerge dev-qt/qtgui-5.11.1, but I get this:
>
># ldd 
>/Net/portage_tmpdir/portage/dev-qt/qtgui-5.11.1/work/qtbase-everywhere-src-5.11.1/bin/qvkgen
>linux-vdso.so.1 (0x7fff3ddff000)
>libQt5Core.so.5 => not found
>libc.so.6 => /lib64/libc.so.6 (0x7f697dbd8000)
>/lib64/ld-linux-x86-64.so.2 (0x7f697e1f5000)
># strings /etc/ld.so.cache | grep libQt5Core.so.5
>libQt5Core.so.5
>/usr/lib64/libQt5Core.so.5
># ls -l /usr/lib64/libQt5Core.so.5*
>lrwxrwxrwx 1 root root  20 Nov  5 12:49 /usr/lib64/libQt5Core.so.5 -> 
>libQt5Core.so.5.11.1
>lrwxrwxrwx 1 root root  20 Nov  5 12:49 /usr/lib64/libQt5Core.so.5.11 -> 
>libQt5Core.so.5.11.1
>-rwxr-xr-x 1 root root 5351376 Nov  5 12:49 /usr/lib64/libQt5Core.so.5.11.1
>
>So why isn't it found ?

Are you using a kernel <3.15?

Found this at :
"Qt 5.10 uses the renameat2 system call which is only available
since kernel 3.15."

The error-message of ld et.al. is rather weird and misleading though.

HTH,
-dnh

-- 
printk(KERN_CRIT "How did I get here?\n");
linux-2.6.19/arch/mips/kernel/syscall.c