2009-01-20

LaCie 5big network

2009-01-16


Just got me a nice Lacie 5Big network disk.
7.5 TB (5 times 1.5 GByte Seagate Barracuda), configured in Raid5, delivers 5.4 TB diskspace.

This system is running a linux, with only interface, a webpage to configure the system.
Can export shares through smb, afs, ftp and http.

plus:

  • runs very silent.
  • relatively easy to configure.
  • very nice design

minus:

  • very limited configurability
  • Users and groups can be defined to determine access control, however, user passwords are limited to 8 chars in the web-interface provided, even though the underlying system *does* take md5 passwords.
  • web page that allows for definition of an e-mail address for the administrator, limits length of e-mail to something as 30 chars
  • *very limited* share configuration: define shares and some access control to it. That's it. No possibility to "finetune" the shares, like creating sub-shares (a share to a portion (subtree) within another share)
  • no possibility to move files from one share to another on system-level... which makes it a pain (for large volumes) to move them from one share to another.
  • The feature to make a snap-shot of an attached USB-disk, produces a new share (each time), but there's no way to check the status of the copy process
All these software remarks would be easily solved if given some direct (shell) access to the system.
  • Comes with an external power adapter brick, that reduces the design-factor by let's say, 100. But might be understandible, it's quickly replacable (in my experience with LaCie power adapters that's a plus), and reduces head production *in* the pretty box.

updated 2009-01-23


I upgraded the system on 2009-01-22 to the recently published firmware (2.1.2.rc4, dated 2009-01-15). Since there's no documentation provided on what the firmware fixes (or not), one can not decide for oneself whether the update brings something you want, or fixes something you have (or have not) as a problem... Only after upgrading, you get to see what's in the package.
Now after the upgrad of the system, the (webpage)console requires you to reboot the system. Which I did. When rebooting, all my (already) filled afp-shares were present, BUT
  • my main share ("share") holding about 2TB of data already, had only first level (root directory) present. In the subdirs, nothing present, no dirs, no files. The webpage "browse" however still shows the content of the shares as they should be.
  • another share (having been created by the "automatic copy of a usb-disk") has the complete contents present, but permissions for the complete share (when mounted) are all set read-only.

In communication with the rather quick and helpfull belgian helpdesk (through web-ticket communication), I discovered en plus that when "removing" a share, the files remain present on the disk (are not removed as well), but the content of the (prior share) becomes unavailable, untill the share with the same name is created again. Bummer if the share was made using the copy-complete-usb-disk feature, that adds some random number after the snap-share...
If you removed that share, your disk stays filled, but you can't access it anymore. I think at least a warning should be given when removing a not-empty share, about the "trailing occupation" of the disk...

Current Status


Ok, data 's on it, and I bought the thing, but currently, for future investments, I'm looking at something like the QNAP TS-639 Pro NAS which provides a vaster amount of functionality for (about) the same price.

2009-01-16

google calender,... event repeat until never, limited to 366

In google calendar faq one can find that events iterations "currently" are limited to 366.
You can create an event to repeat until never, however.
This event will "stop" to be in your google calender 366 iterations AFTER the first instance. If you have a repeating event every working day (like the event "working hours") supposedly never to end, the event stops displaying some 510 days (a year and some months) later (510 - 74 weekend days).

BUT
If you sync that calender (with that event) to iCal (for instance), the event does NOT stop (in iCal) after the expiration date....
So on my google calendar I added a new event (copy of previous), never to end, to be started the day the previous event "disappeared".
After a refresh of my iCal, I found the event twice. Apparently the never-to-end repetitive event *is* exported as never to end, only in google calendar, it stops after these limit iterations.

Workaround:
make the original event "stop" repetition the last day that was reachable, and make the next one start the first now empty.

e.g.
start working days 2007-01-02 .... until 2008-05-26
new event (copy original) start 2008-05-27 ... until (never)... will see when it disappears again.