abs0lut.zer0

pls check my log p.s. am running a pre-clear as i post this sdasmart.txt

sorry to jump in at the end of this conversation but does that mean that your preclear script could suffer from the same fate Joe L. or does it force write and reads to every physical sector ?

Rajahal i am sorry but this post is begging the question why? i am reading this and not one person asks the question.. if it's not private ... what are you doing !!!

As an absolute scripting noob (and not really much of a desire to learn) i very much agree with this statement, this software is fantastic (unRAID) and what the user community brings to it is absolute brilliance but how to make the scripts, plugins and customizations work is sometimes scary to the point of wow that is great but i don't wanna break my already working stable unRAID so lets just watch people that are willing to take the plunge and enjoy the benefits.

confirm that same working on the X8SIL-F ... so that begs the question why have a dedicated port or is it a security feature to put on a different vlan ?

Don't write to a disk you are re-constructing or replacing until the re-construction is complete. thanks will do that then lionelhutz points out that even that is not safe. It really needs to be resolved. The whole md5sum database idea I had seems to be crucial now for verifying your file integrity. so when can we expect it implemented

Don't write to a disk you are re-constructing or replacing until the re-construction is complete. thanks will do that then question: delete is same as a write ?

SOooo ??? ??? as a novice, the global moderators are starting to scare me... is there ANY way to avoid this error or what are best practices.? thanks

Maybe so, but potential new customers don't. Keep in mind, the mere act of mounting a file system creates a write on the file system. If you are recovering from some other issue and the file system is replaying transactions, that is more writes. I suppose if we knew what the driver changes were, we could do it ourselves. Still, this should be tidied up if a crucial bug exists in a stable production release version. This is one situation where I stand with those wanting a fix. I think this old patch to the "md" code describes the issue: http://www.spinics.net/lists/raid/msg33994.html Although there are many changes in the unRAID "md" driver code between the 4.7 version and the 5.0 versions, the old and new lines equivalent to the patch described on spincs.net are Old code in unraid.c /* If we're trying to read a failed disk, then we must read * parity and all the "other" disks and compute it. */ if ((col->read_bi || (failed && sh->col[failed_num].read_bi)) && !buff_uptodate(col) && !buff_locked(col)) { if (disk_valid( col)) { dprintk("Reading col %d (sync=%d)\n", i, syncing); set_buff_locked( col); locked++; set_bit(MD_BUFF_READ, &col->state); } else if (uptodate == disks-1) { dprintk("Computing col %d\n", i); compute_block(sh, i); /* also sets it Uptodate */ uptodate++; /* if failed disk is enabled, write it */ if (disk_enabled( col)) { dprintk("Writing reconstructed failed col %d\n", i); set_buff_locked( col); locked++; set_bit(MD_BUFF_WRITE, &col->state); } /* this stripe is also now in-sync */ if (syncing) set_bit(STRIPE_INSYNC, &sh->state); } } New code in unraid.c in the 5.0beta series (note, the lines noted above in RED are removed. It is not assumed the stripe is in sync.: /* If we're trying to read a failed disk, then we must read * parity and all the "other" disks and compute it. * Note: if (failed > 1) there won't be any reads posted to a * failed drive because they would have been terminated above. */ if ((col->read_bi || (failed && sh->col[failed_num].read_bi)) && !buff_uptodate(col) && !buff_locked(col)) { if (disk_valid( col)) { dprintk("Reading col %d (sync=%d)\n", i, syncing); set_buff_locked( col); locked++; set_bit(MD_BUFF_READ, &col->state); } else if (uptodate == disks-1) { dprintk("Computing col %d\n", i); compute_block(sh, i); /* also sets it Uptodate */ uptodate++; /* if failed disk is enabled, write it */ if (disk_enabled( col)) { dprintk("Writing reconstructed failed col %d\n", i); set_buff_locked( col); locked++; set_bit(MD_BUFF_WRITE, &col->state); } } } Joe L. Sorry Joe L. but for those of us that are not coders what does this mean in english ... Do not take this wrong there was no sarcasm intended just merely wanna understand too.. thanks

Does this bug affect parity rebuilds too? It would affect any rebuild, but a parity rebuild, followed by a parity "check" would detect it, and correct parity. The problem is when re-constructing a data drive, as there is no equivalent "check" As stated, the work-around is NOT to write to a data drive when re-constructing that drive in the array. There is second, equally serious bug in the 4.7 version of unRAID as shown here: http://lime-technology.com/forum/index.php?topic=16523.0 and here http://lime-technology.com/forum/index.php?topic=16471.0 and here: http://lime-technology.com/forum/index.php?topic=15385.0 Attempting to re-construct a super.dat file will result in the MBR of existing data drives being re-written, often pointing to the wrong starting sector. The result, drives that show as un-formatted (until the partitioning is corrected in the MBR) and a potential loss of all data if the unRAID owner does something on their own that wipes the drive. An un-writable super.dat, or a complete replacement of the flash drive will result in this bug showing itself in the 4.7 series. Joe L. once again are these issues being addressed or must we to wait for the 5.x to become stable ?

+1

+1 is there ever gonna be a 4.7.1 or has the 4.x series been abandoned and we have to upgrade to the 5.x series to fix this problem even though it's not stable as said by limetech itself.

they actually have do have something for windows ... it's called flexraid forum.flexraid.com BUT it (at least to me) is very hard to understand and when i did get it working i lost data in a big way through no fault of my own and the program does not have real-time parity.... the ease of use and development of unRAID is light-years ahead and is MUCH more stable.. just my limited opinion... hmm.. just checked it seems that they have released real-time RAID but i am still sure i would not use it... here is an interesting table for the question.. http://snapraid.sourceforge.net/compare.html

my 2 cents on this subject is i have a heat issue sometimes in my country and this definitely does help to keep it a little bit cooler as the drives are also in a 5x3bay which does have fans on it but they are so closely packed together it does not seem to help especially when the wind is just a hot wind.

acknowledged thanks

manipulate the data on the array? e.g copy, delete, move files etc.. thanks for your time.

limetech was online earlier today, so it is most likely that development has not stopped. The last post may have been a month ago but be sure to look at the last activity so see get a true idea of how often LimeTech is on the forum. This statement has been said numerous times, but the same doubt remains. Can the global mods not convince Tom to maybe have a thread that can be updated only by him ... sort of like a blog and if he only types one line a week at least we can see (hear) that development is being done. I work in IT Support and i instruct my guys to report to users even if there is nothing fixed at least they realize they have not been forgotten and surely this cult following deserves this at the very least. This will make a huge difference to people doubts ...

I have been following this thread for a while now and i would like some clarification as to what is the problem as i see it it's just the realtek network cards and the SASLP-MV8 controllers is the BLK_EH_NOT_HANDLED issue just to these controllers.? thanks

not really sure about this plugin but found this with google... http://forums.plexapp.com/index.php/topic/27270-plexbmc-client-for-xbmc/

yeah also hoping someday there might be a windows client... it works so great on my galaxy tab 10.1

just for interest sake if you don't mind what news provider do you use?

i have just finished exactly what you want to do. if you have any data on the disk you wanna remove copy off to another disk first. make note of parity drive (so as not to loose any data if you assign the wrong disk) shut down array remove drive telnet to server type initconfig then all the drives turn blue reassign drives (make sure parity is the right drive) and unRAID starts a parity rebuild and in a while all is protected again .... for copying i used midnight commander ...

+1 i think even if Tom has a thread that is locked only to his posts so we can see what's up would be good. even if we saw a post once in a while we could still know what's happening.

Does zfs allow only spinning up the one drive that has your needed data? That's golden to me For me too! unRaid it spinning up only one drive, and it all the possibilites too use diferent disks is real unique! +1

thank you just did it and worked exactly as i wanted it too.