You are not logged in.
Have extended my Logical Volume out to 2.5 TBs, but the disk is unable to see beyond the original 1TB that was allocated.
Performed the partition add steps, and it is visible in vgdisplay and lvdisplay, but LessFS appears to not be seeing these changes.
[root@HQNAS xsinas-files]# df -h *
Filesystem Size Used Avail Use% Mounted on
lessfs 985G 545G 390G 59% /xsinas-files
lessfs 985G 545G 390G 59% /xsinas-files
[root@HQNAS xsinas-files]# lvdisplay
--- Logical volume ---
LV Path /dev/vg_xsinasfs/lv_xsinasfs
LV Name lv_xsinasfs
VG Name vg_xsinasfs
LV UUID 7drbUG-uVcQ-obWe-m1Pb-uGBu-IofQ-aVtjcP
LV Write Access read/write
LV Creation host, time XSINAS, 2016-08-09 14:37:03 +0200
LV Status available
# open 1
LV Size 2.44 TiB
Current LE 639996
Segments 3
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
--- Logical volume ---
LV Path /dev/vg_xsinas/lv_root
LV Name lv_root
VG Name vg_xsinas
LV UUID CmV5Za-vVbl-k03w-ik1X-5fN8-aGLv-6YZXDm
LV Write Access read/write
LV Creation host, time XSINAS, 2016-08-09 15:45:27 +0200
LV Status available
# open 1
LV Size 17.51 GiB
Current LE 4482
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Logical volume ---
LV Path /dev/vg_xsinas/lv_swap
LV Name lv_swap
VG Name vg_xsinas
LV UUID FfgOIh-u5a9-S3gb-iZ8Y-0d0t-NKi7-317diR
LV Write Access read/write
LV Creation host, time XSINAS, 2016-08-09 15:45:30 +0200
LV Status available
# open 1
LV Size 2.00 GiB
Current LE 512
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
[root@HQNAS xsinas-files]# vgdisplay
--- Volume group ---
VG Name vg_xsinasfs
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 3
Act PV 3
VG Size 2.44 TiB
PE Size 4.00 MiB
Total PE 639996
Alloc PE / Size 639996 / 2.44 TiB
Free PE / Size 0 / 0
VG UUID tY6EpB-zExP-cfys-m4Qf-4K9F-XMkE-Ku91mh
--- Volume group ---
VG Name vg_xsinas
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 19.51 GiB
PE Size 4.00 MiB
Total PE 4994
Alloc PE / Size 4994 / 19.51 GiB
Free PE / Size 0 / 0
VG UUID ap4AxO-6JEc-iUmM-zMHY-WVCH-Sn3z-IgslNe
i've rebooted the machine, and restarted the LessFS service, but am still unable to get the additional space to appear.
Thanks,
Cam
Offline
Please, follow every step in the acompanying guide and make sure you are not skipping anything. The procedure has been revised a number of times.
Does the OS see the disk in full size?
Have you reinitialized the LessFS repository?
Maybe you are assuming you can add up space and keep your data.
Also take the following into account:
XSINAS is probably the lightest deduplication appliance, in any case, as any other inline deduplicated FS is very hungry in resources and those resources needs will grow up exponentially. XSIBACKUP-PRO offers XSITools which is a much more convenient way to deduplicate your VM's data once you cross a certain limit in size. Using XSINAS as a realtime FS is not recommended and you do it at your own risk.
Still XSINAS can be a very helpful tool in some circumstances, just as long as you never forget what it is, how it works and what are its limits (just like a knife).
Last edited by roberto (2017-08-02 08:14:20)
Offline
I went through the entire manual, and did the process 3 times but was unable to get it working.
I verified I had the latest manual by downloading from the Google Drive link the latest version.
I also tried out XSITools to a different vmfs, but I got an error when I tried to power on the backed up VM,
Error: Failed to start the virtual machine.
Module Disk power on failed.
Cannot open the disk '/vmfs/volumes/47df2618-9ae011e2/20170625160356/CentralCam/CentralCam.vmdk' or one of the snapshot disks it depends on.
The file specified is not a virtual disk
I'm moving back to a non-deduplicated fs in the meantime, as this is a large dataset for our Central Office, but thank you for the time and response,
Cam
Offline
### Forum admin 2017-08-02 ###
1 - XSITools is a dedupication tool, you can't use it to backup to an inline already deduplicated FS like LessFS. Well, you can do whatever you want, but it's useless, you want get any benefit and it will soon clogg your hardware.
2 - XSITools stores chunks of data in repositories, you can't turn on a VM backed up in an XSITools repository, you must first restore it to a regular datastore.
### Support ###
You will get better results if you use XSITools on a NAS device with a regular FS like EXT4, EXT3 or XFS, as their limits are far beyond VMFSs, in any case VMFS should offer you margin enough to accumulate some Tb of data.
Have you used the restore command to restore the VM from the XSITools repository?, or you are trying to switch it on directly from the repo?.
For this type of personalized support requests, please contact Support if you are a Pro user, we'll be glad to help you. The forum should be used for more general topics.
Offline
I have had the exact same problem. Tried 10 times and followed the manual 100% and still only 1gb. I don't know why (maybe esxi version, disk size....etc) but in our case, the manual is missing the following command at the end:
resize2fs /dev/vg_xsinasfs/lv_xsinasfs
After about 15mins the command completed and disk is now the full size. Maybe consider adding this command in the manual.
I hope it helps!
Offline
Thank you so much for your feedback, you are right. We will correct this and add the final command. It's a kind of obvious for more experienced LVM users, as otherwise the added chunk remains as unused space, but less obvious for people just wanting to extend the XSINAS appliance size.
XSINAS is O.K., it's a useful appliance in SMEs scenarios, but some people which don't fully understand what block deduplication is, just take for granted that it will work as any other regular FS when it obviously doesn't. The FS will slow down as you add data to it.
We have been extremely conservative when configuring XSINAS, so that nobody inadvertedly "hurts himself" by not fully understanding the concept behind. If you want to take the appliance to its limits, you should consider switching to Tokio Cabinet and using fast PCI SSDs. It will multiply its possibilities. Nevertheless, take on account that Tokio Cabinet may loose data in extreme circumstances, like a power outage, while BerkeleyDB has been programmed to be more robust, but lacks Tokio Cabinet speed.
Offline