@prostuff1:  It looks like one of the SQL daemons died.  Try stopping SS and restarting it.  FWIW, I've seen a lot of perl warnings and other output that indicates the SS perl code ion Linux s not necessarily A grade work.

 

Yeah, and it keeps dying.  I can get it up and running for about 30 seconds but then it just shits out on me.  Had it working quite nicely and was loving the streaming to computers at work.

 

When i get some free time and don't have to study for school stuff i will see what i can do about fixing this.  All i wanted to do was add some music to my library, wish i had refrained now.

Just delete the whole slimserver directory contents, and reinstall it.

Just delete the whole slimserver directory contents, and reinstall it.

 

was in the process of doing that.  Figured i had nothing to lose and if it does not work i then get to do my research.

 

EDIT: Yup that worked

Ok, what i did was: when the parity-building process was about 10% (under bubbaraid) i decided to break it and roll back to normal unraid. Then i restored the configuration and built the parity another time. What is intressting is that the newest super.dat file is different to the oldest (before playing with bubba). But all disks and data seem to be ok. Today, i tried to install bubbaraid once again and all disks were shown as missing again, so i again rolled back to unraid and everything was ok there.

 

BubbaQ, there must be something wrong in your distro with disks identification. You must fix it to make it safe to use.

 

I attach a syslog from running bubbaraid today: http://rapidshare.com/files/156041764/syslog.rar.html

here is that syslog direct access to read rather than horrible rapidshare

 

http://pastebin.com/f77171da6

What is intressting is that the newest super.dat file is different to the oldest (before playing with bubba). But all disks and data seem to be ok.

The super.dat file includes timestamps and counters:

 

Every time you start or stop the array the "Array state" is  modified.

Every time you perform a "parity check" the "last sync time" and "last sync error count" are updated.

Any time anything listed above is updated in the superblock the "Superblock update time and count" and the "checksum of the whole superblock" are updated.

It is for these reasons you must leave the flash drive plugged into the array when it is running.

 

I would worry if the superblock had the same checksum after all the actions you have performed.

[pre]typedef struct mdp_superblock_s {

        /*

         * Common information

         */

        __u32 md_magic;         /*  0 MD identifier                           */

        __u32 major_version;    /*  1 major version to which the set conforms */

        __u32 minor_version;    /*  2 minor version ...                       */

        __u32 patch_version;    /*  3 patchlevel version ...                  */

        __u32 sb_csum;          /*  4 checksum of the whole superblock        */

        __u32 ctime;            /*  5 Array Creation time                     */

        __u32 utime;            /*  6 Superblock update time                  */

        __u32 events;           /*  7 Superblock update count                 */

        __u32 md_minor;         /*  8 preferred MD minor device number        */

        __u32 state;            /*  9 array state                             */

        __u32 num_disks;        /* 10 number of disks in the array            */

        __u32 stime;            /* 11 Last sync time                          */

        __u32 sync_errs;        /* 12 Last sync error count                   */

        __u32 common_reserved[MD_SB_COMMON_WORDS - 13];

        /*

         * Disks information

         */

        mdp_disk_t disks[MD_SB_DISKS];

 

        /*

         * Reserved

         */

        __u32 reserved[MD_SB_RESERVED_WORDS];

} mdp_super_t;

[/pre]

 

Joe L.

@Koperfild, please post the syslog from the regular unRAID also, so I can compare the differences.

Here it is: http://pastebin.com/m2c901bdb

 

My answer to the question asked in the topic name is NUT (Network UPS Tools) - a program which controls UPS condition and turns the system of in cases of emergency. It's something similar to that "APC Tools" which are already in bubbaraid, but better configurable and works with uncomparably more ups brands.

 

P.S. Does the bubbaraid automatically apply the "20% read performance hit" trick? If not maybe it would be a good feature...

 

 

I am downloading BubbaRaid 0.0.7 and rTorrent stay not working.

@Koperfild, are you using user shares?

Yes, i do.

I think that must be the problem.  I've found some differences in the Fuse version between unRAID 4.3.3 and BubbaRaid, and they are reflected in the two different syslogs.

 

I don't use user shares, so I didn't see this before.  I'll look into it, but for the time being, I'm going to have to limit BubbaRiad to regular shares, and not User Shares.

I don't use user shares, so I didn't see this before.  I'll look into it, but for the time being, I'm going to have to limit BubbaRiad to regular shares, and not User Shares.

Wait, user shares are when unraid merges two folders with the same name located on different disks into one? If so, deleting this feature you will kill the bubba raid project for me! When i saw that distro i really thought i would eventually be able to use my unraid box as torrent downloading machine, web server, and i generally was happy to see something new, as tom's progress has been hardly any last times... Now, without user shares it is going to be another unusefull project

Hold on a sec...  User shares can be enabled, the issue is that rtorrent cannot utilize the user share as the filesystem from which it reads or writes.

 

That is.. rtorrent and the current fuse/kernel environment must use /mnt/disk1/torrent instead of /mnt/user/torrent.

The issue is with the current version of fuse and the mmap call.

rtorrent uses mmap to map a file into memory and that system call is not compatible with fuse and the current kernel.

This has been fixed in later kernels, so it's only temporary.

 

I have user shares enabled, yet all my rtorrent path defintions point to /mnt/disk1/bittorrent.

This is working without

Webo is right.... although there is a slight version difference in the Fuse FS, the problem appears to be with rTorrent, not BubbaRaid.  I created a user share on a stock unRAID 4.3.3 and installed rTorrent, and rTorrent doesn't work with the user share, but will work with regular disk shares.

 

 

So the apps included in bubbaraid will just not work with user shares but the unraid engine will still offer user shares feature right? It's ok for me this way.

 

so when can we expect beta 0.0.8 with corrected disk recognition?

So the apps included in bubbaraid will just not work with user shares...

 

rtorrent is the only issue because it uses a call not supported by fuse/user shares. It will work with direct disk shares.

 

As to a release where rtorrent works on user shares, I think this depends on the latest kernel being released within unRAID itself.

 

@Ropo, are you using user shares?

Bubba when are you going to relase new beta which will recognise my drives (so thet they are not all read)? I am really looking forward to see it...

@Koperfild, I'm still looking at your logs.  I need to understand exactly what was happening in your system first.

 

Frankly, it has me baffled right now... except for the minor difference in Fuse version, I can't point the finger at anything.  I can't reproduce the problem on my test systems.

I'm open to suggestions to perform some additional tests to help you working the problem out.

bubbaQ,

 

I am having similar problems (too many wrong or missing disks!).  I installed v0.7 on my 4.3.3 stick, ran the batch file and then booted the array.  Attached are a picture and both syslogs (BubbaRaid and Normal) for comparison.  I've reverted to the normal status and all seems fine again.  Let me know if more info is needed.

 

Regards,  Peter

 

p.s. I am running a parity check again just to be safe...

 

 

 

bubbaQ,

 

I am having similar problems (too many wrong or missing disks!).  I installed v0.7 on my 4.3.3 stick, ran the batch file and then booted the array.  Attached are a picture and both syslogs (BubbaRaid and Normal) for comparison.  I've reverted to the normal status and all seems fine again.  Let me know if more info is needed.

 

Regards,  Peter

 

p.s. I am running a parity check again just to be safe...

 

 

 

You are probably fine.  The bug seems to be the exact same one Tom addressed in the 4.3.3 release of unRaid as described here:  http://lime-technology.com/forum/index.php?topic=2235.0

 

BubbaQ,

in md.c, in function same_disk_info, you probably need to modify the source of the driver you compiled as Tom did his, to truncate the model numbers to 20 characters.

 

Joe L.

 

Joe L,

 

Yep.  The parity check showed no ill effects.  So I will stay with 4.3.3 until there is an update for this bug in BubbaRaid.

 

Thanks and regards,  Peter

I've made some application improvements, but I'm going to wail till Tom releases unRAID 4.4 before releasing another BubbaRaid, so I can upgrade to 4.4 ad the new kernel.