Synology & Fsck

[Jack]

Almost forgot, could be a huge open file somewhere.
Try using lsof to find deleted still open files or the cause of the discrepancy.

Jack

--- On Wed, 6/2/10, Kelsay, Brian - Kansas City, MO <brian.kelsay at kcc.usda.gov> wrote:

From: Kelsay, Brian - Kansas City, MO <brian.kelsay at kcc.usda.gov>
Subject: Re: Synology & Fsck
To: "'kclug at kclug.org'" <kclug at kclug.org>
Date: Wednesday, June 2, 2010, 12:03 PM


Are there any temp files or old logs that you can delete to free up space for fresh firmware?

--------------------------

Brian Kelsay

Sr. IT Support Specialist

Anadarko Industries Inc. working for

Technical Support Division (TSD)

USDA/OCIO/ITS/TSD/LO-KC

Office: 816-823-4859

Mobile: 816-769-5615

Email: brian.kelsay at kcc.usda.gov

Message Sent using BlackBerry Device





From: kclug-bounces at kclug.org <kclug-bounces at kclug.org>

To: KCLUG <kclug at kclug.org>

Sent: Wed Jun 02 12:08:30 2010
Subject: Re: Synology & Fsck



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 -kFilesystem           1K-blocks      Used Available Use% Mounted onrootfs                 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.



-----Inline Attachment Follows-----

_______________________________________________
KCLUG mailing list
KCLUG at kclug.org
http://kclug.org/mailman/listinfo/kclug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kclug.org/pipermail/kclug/attachments/20100602/3dc2107a/attachment.htm>