WeeboTech Posted April 9, 2008 Share Posted April 9, 2008 "Because to me, every "support" issue brought up in this thread is a valid "announcement" about that beta, giving users potentially critical information about the current beta, what works, what doesn't, and what problems users are having with it." I agree with cohiba for the very same reason Quote Link to comment
PhilH Posted April 9, 2008 Share Posted April 9, 2008 I guess I'll put my 2 cents in.. I like having any questions or troubles people are having in the same thread as the announcement. Makes it easy for me to decide if I want to try this particular beta or not.. Phil Quote Link to comment
NAS Posted April 9, 2008 Share Posted April 9, 2008 All fair points. What i will do is just ignore completely all but the initial post. I really don't have the time to follow the various ramblings all bundled together into one amorphous blob. As for the "one post to rule them all" theory... i couldnt disagree more... thats why there a forum with subjects and topics. Im not going to labor the point only to say if i wanted to be in a chat room i would Tom any chance you could have a discrete changelog to follow for those of us not wanting to read war and peace looking for the relevant bits? Quote Link to comment
sirwired Posted April 10, 2008 Share Posted April 10, 2008 It looks like a login prompt to me, just with some logging messages appended to your display... Hit enter, and you should see the plain login prompt again. SirWired Quote Link to comment
JarDo Posted April 14, 2008 Share Posted April 14, 2008 Can someone help me understand this please. My rsync backups appear to be working with the new v4.3b6 release but I receive the following error for every file that is copied during the rsync session: rsync: chown "/mnt/user/backup/fs1/projects/nas/unraid/flash/user/packages/.readme.rtf.hx5pS6" failed: No such file or directory Some observations: 1) I do not receive these errors if I roll back to v4.2 (I tested this today) 2) The dot in front of the file name doesn't really exist in the source or destination file, only in the error message 3) The dot.6 characters (".hx5pS6" in the example above) don't appear in the source or destination file, only in the error message 4) The dot.6 characters are unique for every file error message 5) I do not have a cache drive enabled in my configuration It appears to me that v4.3 clearly handles files in a manner different from v4.2 and it is tripping up rsync. I just don't understand enough about the changes from v4.2 to v4.3 to diagnose the issue. Any info/insight is appreciated. Quote Link to comment
WeeboTech Posted April 14, 2008 Share Posted April 14, 2008 Are you using the user shares or direct disk shares? I would suggest switching to the opposite just to check the issue. the dot prefixed file is a temp file. rsync first copies the file to a dot prefixed temp file. Quote Link to comment
NLS Posted April 14, 2008 Share Posted April 14, 2008 the format above is shown DURING a file copy i.e. the file is named smth like that, WHILE it is going to the destination (at the destination) and when the file finishes, it gets renamed to its original name so probably rsync created the list of files to sync while a file was copied (by you) and when rsync reached the file, that file of course was copied already so that temp filename was not there Quote Link to comment
JarDo Posted April 15, 2008 Share Posted April 15, 2008 Well, I am using user shares. But it wasn't a problem until v4.3. Here's the cron job I'm running once per day: #!/bin/bash # # Title: *_blacky_rsync.sh # # Summary: # The purpose of this script is to 'PULL' a backup off of a remote rsync server to a local destination on the client. # # rsync source sSrc="blacky::fs1" # rsync destination sDest="/mnt/user/backup/fs1" # rsync parameters sParms="-amv --delete" # -a archive mode; same as -rlptgoD (no -H preserve hard links) # -rlptgoD # -r recurss into directories # -l copy symlinks as symlinks # -p preserve permissions # -t preserve times # -g preserve group # -o preserve owner (super-user only) # -D same as --devices --specials # --devices preserve device files (super-user only) # --specials preserve special files # -m prune empty directory chains from the file-list # --delete delete files that don't exist on the sending side # Here's the magic: rsync $sParms $sSrc $sDest # My job here is done exit For the record I do not have the cache drive enabled at all. However, I did test with a cache drive enabled and it did work however with the same exact error messages. The files even went to the cache drive as their first stop prior to being written to the RAID volumes. That was a good thing as it seems that the new cache feature might speed up my rsync's if I can fix the 'chown error' introduced with v4.3. Quote Link to comment
WeeboTech Posted April 15, 2008 Share Posted April 15, 2008 I would consider this an issue root@unraid:/mnt/user/video# touch x.x root@unraid:/mnt/user/video# ls -l x.x -rw-r--r-- 1 root root 0 Apr 14 22:42 x.x root@unraid:/mnt/user/video# chown root:root x.x chown: changing ownership of `x.x': No such file or directory This works fine root@unraid:/mnt/user/video# cd /mnt/disk1/video root@unraid:/mnt/disk1/video# ls -l x.x -rw-r--r-- 1 root root 0 Apr 14 22:42 x.x root@unraid:/mnt/disk1/video# chown root:root x.x root@unraid:/mnt/disk1/video# Quote Link to comment
madshi Posted April 15, 2008 Share Posted April 15, 2008 Gone from 4.2.1 to 4.3-beta6 - ... - and everything works fine for me. The cache disk works well. Thank you! One minor annoyance with the cache drive: When the moving to the real array is done, the cache drive ends up with a full directory tree with no contents in it. In my case I ended up with >30 empty directories on the cache drive. It's not really a critical issue, but it's not "nice". Wouldn't it be possible to delete the empty directories after a successful move of the cached data to the real array? Quote Link to comment
Joe L. Posted April 15, 2008 Share Posted April 15, 2008 Wouldn't it be possible to delete the empty directories after a successful move of the cached data to the real array? You can add something like this to the "mover" script, or just execute it by hand once in a while. find /mnt/cache/* -depth -type d -empty -exec rmdir {} \; Joe L. Quote Link to comment
NLS Posted April 15, 2008 Share Posted April 15, 2008 Maybe there is a reason Tom leaves those in? Quote Link to comment
JarDo Posted April 15, 2008 Share Posted April 15, 2008 I would consider this an issue root@unraid:/mnt/user/video# touch x.x root@unraid:/mnt/user/video# ls -l x.x -rw-r--r-- 1 root root 0 Apr 14 22:42 x.x root@unraid:/mnt/user/video# chown root:root x.x chown: changing ownership of `x.x': No such file or directory This works fine root@unraid:/mnt/user/video# cd /mnt/disk1/video root@unraid:/mnt/disk1/video# ls -l x.x -rw-r--r-- 1 root root 0 Apr 14 22:42 x.x root@unraid:/mnt/disk1/video# chown root:root x.x root@unraid:/mnt/disk1/video# So, do you think that there may be an issue with User Shares in the new version? Quote Link to comment
Joe L. Posted April 15, 2008 Share Posted April 15, 2008 Looks like the chown command is not properly implemented in the user file system. Quote Link to comment
WeeboTech Posted April 15, 2008 Share Posted April 15, 2008 Agreed, and we also know that the userfs was re-written, so a few bugs or unimplemented features may exist. Quote Link to comment
aaron330i Posted April 17, 2008 Share Posted April 17, 2008 Grats on beta6. Installed it on 4/2 with a 250GB cache disk and it has been up and running with zero downtime since then. What a huge difference the cache disk makes in the performance of the system. I love it. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.