Synology & Fsck

[Sean Crago]

On Wed, Jun 2, 2010 at 10:47 PM, Sean Crago <cragos at gmail.com> wrote:

> If the list is coming back to life, then I've got a weird but hopefully
> simple problem for you:
>
> I've got a Synology DiskStation DS209 NAS that's giving me erroneous free
> space readings, or erroneous du output. On installation, it dedicated 2.4GB
> to its root partition /dev/md0 and according to du -cx / is using less than
> 587192K of that space. Unfortunately, however, df says it's full.
>
> bash-3.2# df -k
> Filesystem           1K-blocks      Used Available Use% Mounted on
> rootfs                 2451064   2425764         0 100% /
> /dev/root              2451064   2425764         0 100% /
>
> bash-3.2# mount
> /dev/md0 on / type ext3 (rw,data=ordered)
>
> As a result, any number of apps from the stock firmware are prevented from
> running and those that do hobble along spam the logs to the point of
> uselessness w/complaints. The catch? I can't find a safe way to fsck it.
> Conventional shutdown commands to force a fsck aren't an option/are just
> plain missing on the box. Using tune2fs to set the check
> interval ridiculously low to force a check upon reboot similarly didn't
> work. Unfortunately, the ARM-based architecture also doesn't support booting
> to a removable USB device, knocking out the only other safe way I can think
> of to fsck it. Pop new firmware on to start from scratch? I'd love to at
> this point, but the firmware installation process requires 1024 megs of free
> disk space.
>
> Thoughts?  Any ideas on how to safely get it cleaned up and accurately
> reporting its free space while the root filesystem is live and booted?
>
> -Sean
>

Oh, and I really doubt this changes the solution, but for full disclosure's
sake:

Last change I made to the system was to install the ipkg for mlocate, which
stores its small 500k db on a different partition. Also, power situation is
abysmal here, and I'm not convinced it's shutting down properly when it
detects that it's on UPS power.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kclug.org/pipermail/kclug/attachments/20100602/a99d32f8/attachment.htm>