Re: Massive loss of disk space

2017-08-03 Thread pwm
In 30 seconds I should be able to fill about 200MB * 30 = 6GB. Requiring the parity to not grow larger than there is a 6GB additional space is possible to live with on a 10TB disk. It seems that for SnapRAID to have any chance to work correctly with parity on a BTRFS partition, it would need

Re: Massive loss of disk space

2017-08-01 Thread pwm
2017, Austin S. Hemmelgarn wrote: On 2017-08-01 11:24, pwm wrote: Yes, the test code is as below - trying to match what snapraid tries to do: #include #include #include #include #include #include #include int main() { int fd = open("/mnt/snap_04/snapraid.parity",O_NOFOL

Re: Massive loss of disk space

2017-08-01 Thread pwm
on. int fallocate(int fd, int mode, off_t offset, off_t len); What you are implying here is that if the fallocate() call is modified to: res = fallocate(fd,0,old_size,new_size-old_size); then everything should work as expected? /Per W On Tue, 1 Aug 2017, Austin S. Hemmelgarn wrote: On 2017

Re: Massive loss of disk space

2017-08-01 Thread pwm
Thanks for the links and suggestions. I did try your suggestions but it didn't solve the underlying problem. pwm@europium:~$ sudo btrfs balance start -v -dusage=20 /mnt/snap_04 Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=20 Done, had to relocate

Massive loss of disk space

2017-08-01 Thread pwm
. that the disk is full. Machine was originally a Debian 8 (Jessie) but after I detected the issue and no btrfs tool did show any errors, I have updated to Debian 9 (Snatch) to get a newer kernel and newer btrfs tools. pwm@europium:/mnt$ btrfs --version btrfs-progs v4.7.3 pwm@europium:/mnt$ uname -a Linux