/var/hda/files full-cant write to shares(landing zone full?)

afrik
Posts: 3
Joined: Sun Mar 20, 2011 4:24 pm

/var/hda/files full-cant write to shares(landing zone full?)

Postby afrik » Mon Mar 21, 2011 12:52 pm

Hello,

I'm new to Amahi / Greyhole - Just moved from WHS.

I experience some issues with Greyhole probably due to series of mistakes made cause lack of proper understanding the process.
My small partition (landing zone?) SDA3 was filling up quickly and could not get that balanced properly so I removed it using greyhole --going and through Amahi interface. Before that I also tried changing min_free (using PHPmyadmin) - with no success. Sadly, the problem still exists - /var/hda/files is filled up and it prevents me from writing to my shares.

I guess I'd need to change the landing zone to one of my 2tb drives, not sure how though without any risk of loosing my data that is currently stored in there.

If it's easier to start from scratch - I'm happy to do that - I just need some guidance in terms of safely moving all existing data to one of the HDDs and than re-importing it to Greyhole.

I hope you can help me with getting it right.

1. What version of Fedora, Samba & Greyhole are you running?
uname -r
2.6.35.11-83.fc14.x86_64
rpm -q samba hda-greyhole
samba-3.5.6-71.fc14.x86_64
hda-greyhole-0.9.2-1.x86_64
2
smb.conf
http://fpaste.org/0Ghg/
greyhole.conf
http://fpaste.org/GIH9/
greyhole.yml
http://fpaste.org/cxga/
3.
mount
/dev/mapper/vg_trevor-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext4 (rw)
/dev/mapper/vg_trevor-lv_home on /home type ext4 (rw)
/dev/sda3 on /var/hda/files type ext4 (rw)
/dev/sdb1 on /var/hda/files/drives/drive1 type ext4 (rw)
/dev/sdc1 on /var/hda/files/drives/drive2 type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
gvfs-fuse-daemon on /home/afrik/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=afrik)
fdisk -l

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x69916337

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 103426047 51200000 8e Linux LVM
/dev/sda3 103426048 488396799 192485376 83 Linux

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x838dd052

Device Boot Start End Blocks Id System
/dev/sdb1 1 3907029167 1953514583+ ee GPT

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5bfab12b

Device Boot Start End Blocks Id System
/dev/sdc1 2048 3907028991 1953513472 83 Linux

Disk /dev/dm-0: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/dm-1: 29.3 GB, 29293019136 bytes
255 heads, 63 sectors/track, 3561 cylinders, total 57212928 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Disk /dev/dm-2: 21.0 GB, 20971520000 bytes
255 heads, 63 sectors/track, 2549 cylinders, total 40960000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_trevor-lv_root
27G 4.1G 22G 16% /
tmpfs 436M 424K 435M 1% /dev/shm
/dev/sda1 485M 49M 411M 11% /boot
/dev/mapper/vg_trevor-lv_home
20G 222M 19G 2% /homehttp://fpaste.org/xQGL/
/dev/sda3 181G 172G 86M 100% /var/hda/files
/dev/sdb1 1.8T 421G 1.3T 25% /var/hda/files/drives/drive1
/dev/sdc1 1.8T 420G 1.3T 25% /var/hda/files/drives/drive2
greyhole --stats

Greyhole Statistics
===================

Storage Pool
Total - Used = Free + Attic = Possible
/var/hda/files/drives/drive1/gh: 1834G - 420G = 1320G + 50G = 1370G
/var/hda/files/drives/drive2/gh: 1834G - 419G = 1321G + 0G = 1321G
==========================================
Total: 3668G - 840G = 2641G + 50G = 2692G

4. The list drives in your storage pool (per Amahi platform):
mysql -u root -phda -e "select * from disk_pool_partitions" hda_production

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)


5. A list of the directories on the root of the drives included in your storage pool, obtained with the following command (provide a paste URL):
http://fpaste.org/xQGL/

6. The Greyhole work queue:

Greyhole Work Queue Statistics
==============================

This table gives you the number of pending operations queued for the Greyhole daemon, per share.

Write Delete Rename
AudioBooks 0 0 0
Books 0 0 0
Docs 0 0 0
Edukacja 0 0 0
Ewa_Docs 0 0 0
Ewa_Edu 0 0 0
Kuchnia 0 0 0
Movies 0 0 0
Music 0 0 0
Pictures 0 0 0
Tom_Edu 0 0 0
Warezzz 0 0 0
==========
Total 0 + 0 + 0 = 0

The following is the number of pending operations that the Greyhole daemon still needs to parse.
Until it does, the nature of those operations is unknown.
Spooled operations that have been parsed will be listed above and disappear from the count below.

Spooled 0

tail /var/log/greyhole.log
Mar 20 22:58:38 7 sleep: Nothing to do... Sleeping.
Mar 20 22:58:48 7 sleep: Nothing to do... Sleeping.
Mar 20 22:58:58 7 sleep: Nothing to do... Sleeping.
Mar 20 22:59:08 7 sleep: Nothing to do... Sleeping.
Mar 20 22:59:18 7 sleep: Nothing to do... Sleeping.
Mar 20 22:59:28 7 sleep: Nothing to do... Sleeping.
Mar 20 22:59:38 7 sleep: Nothing to do... Sleeping.
Mar 20 22:59:48 7 sleep: Nothing to do... Sleeping.
Mar 20 22:59:58 7 sleep: Nothing to do... Sleeping.
Mar 20 23:00:08 7 sleep: Nothing to do... Sleeping.




many thanks :)
a.

User avatar
gboudreau
Posts: 606
Joined: Sat Jan 23, 2010 1:15 pm
Location: Montréal, Canada
Contact:

Re: /var/hda/files full-cant write to shares(landing zone fu

Postby gboudreau » Tue Mar 22, 2011 3:22 am

How did you copy the files into your shares ?

If the landing zone is still full, and Greyhole says it has nothing to do, it's probably because you added files in /var/hda/files/share_name without using Samba. Or because those files are in the Viglen or Kamera shares, which to no use the storage pool.

Do a greyhole --fsck to fix the first.
If you'd like to continue copying directly to /var/hda/files for the initial data migration, you cna do so, but you'll need to stop copying each time the landing zone is full, and issue a --fsck command to have Greyhole move the files into the pool.
- Guillaume Boudreau

afrik
Posts: 3
Joined: Sun Mar 20, 2011 4:24 pm

Re: /var/hda/files full-cant write to shares(landing zone fu

Postby afrik » Tue Mar 22, 2011 2:10 pm

gboudreau,

Many thanks for you post. Not sure which solution helped as I tried both. I can see files are being moved, which is great!

Clearly my fault though - I missed those two shares - did not add them to the pool.

I'm planning to get another HDD soon, so I will be looking for information on how to move the landing zone to the new drive but will ask for some help in a another post, as this issue is now sorted!

many thanks once again :)

a.

Who is online

Users browsing this forum: No registered users and 13 guests