New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AFP export doesn't expand when underneath share (subvolume in btrfs) expands #614

Closed
freeurmind opened this Issue Mar 5, 2015 · 6 comments

Comments

Projects
None yet
5 participants
@freeurmind

freeurmind commented Mar 5, 2015

Reproduce steps:

  1. Create a 10GB share (subvolume) in btrfs
  2. Export this 10GB share (subvolume) thru AFP
  3. Mount 10GB share, df -h shows 10GB free space
  4. Expand above share (subvolume) to 20GB in btrfs
  5. Mount share, df -h still shows 10GB
  6. You will have to delete/ re-create the AFP share to get the Mac see 20GB free space
@schakrava

This comment has been minimized.

Show comment
Hide comment
@schakrava

schakrava Mar 5, 2015

Member

Thanks for opening this issue. We'll test it out, but my current theory is that this is just a matter of wrong reporting. If I am right, you should still be able to write more than 10GB. If you can try that out and add your comments, it would be great!

Member

schakrava commented Mar 5, 2015

Thanks for opening this issue. We'll test it out, but my current theory is that this is just a matter of wrong reporting. If I am right, you should still be able to write more than 10GB. If you can try that out and add your comments, it would be great!

@schakrava schakrava added this to the Yosemite milestone Mar 5, 2015

@schakrava schakrava added the bug label Mar 5, 2015

@freeurmind

This comment has been minimized.

Show comment
Hide comment
@freeurmind

freeurmind Mar 6, 2015

Did a quick "dd" test on 1GB subvolume/share, expanded to 2GB, able to write 1.5GB file via AFP, which shows you are correct, it should merely be an issue of wrong reporting.

The reason I noticed this is because my Time Machine backup constantly fails complaining not enough free space, caught the wrong reporting during regular check. The problem is gone after I expanded subvolume and re-created AFP share.

freeurmind commented Mar 6, 2015

Did a quick "dd" test on 1GB subvolume/share, expanded to 2GB, able to write 1.5GB file via AFP, which shows you are correct, it should merely be an issue of wrong reporting.

The reason I noticed this is because my Time Machine backup constantly fails complaining not enough free space, caught the wrong reporting during regular check. The problem is gone after I expanded subvolume and re-created AFP share.

@freeurmind

This comment has been minimized.

Show comment
Hide comment
@freeurmind

freeurmind Mar 7, 2015

Turns out "df -h" gives whatever it is in "vol size limit = xxx" on each share in /etc/afp.conf

So the issue is, "vol size limit = xxx" in /etc/afp.conf doesn't get updated after btrfs subvolume expands. I did try to remove this line on specific subvolume, "df -h" instead gives free space on /, which is not what we want either.

freeurmind commented Mar 7, 2015

Turns out "df -h" gives whatever it is in "vol size limit = xxx" on each share in /etc/afp.conf

So the issue is, "vol size limit = xxx" in /etc/afp.conf doesn't get updated after btrfs subvolume expands. I did try to remove this line on specific subvolume, "df -h" instead gives free space on /, which is not what we want either.

@schakrava

This comment has been minimized.

Show comment
Hide comment
@schakrava

schakrava Mar 7, 2015

Member

Cool. You practically solved this for us. It's just a matter of coding it up. Thanks!

Member

schakrava commented Mar 7, 2015

Cool. You practically solved this for us. It's just a matter of coding it up. Thanks!

@sambucka

This comment has been minimized.

Show comment
Hide comment
@sambucka

sambucka Apr 12, 2016

I had a similar issue. Created pool, created share (it defaulted to 1GB soft limit). Created AFP share. Mounted AFP and it showed 1TB volume, also it showed 1TB after opening TimeMachine, but once backup was started it errored out that there is not enough space (1GB available only). I have deleted the share and recreated with soft limit of 1TB and was able to backup with TimeMachine.

sambucka commented Apr 12, 2016

I had a similar issue. Created pool, created share (it defaulted to 1GB soft limit). Created AFP share. Mounted AFP and it showed 1TB volume, also it showed 1TB after opening TimeMachine, but once backup was started it errored out that there is not enough space (1GB available only). I have deleted the share and recreated with soft limit of 1TB and was able to backup with TimeMachine.

@phillxnet

This comment has been minimized.

Show comment
Hide comment
@phillxnet

phillxnet Apr 12, 2016

Member

@sambucka Thanks for the confirmation on this one.

Member

phillxnet commented Apr 12, 2016

@sambucka Thanks for the confirmation on this one.

@schakrava schakrava modified the milestones: Looney Bean, Yosemite Apr 13, 2016

@schakrava schakrava assigned schakrava and unassigned sujeetsr Apr 13, 2016

@schakrava schakrava modified the milestones: Pinnacles, Looney Bean Dec 1, 2016

@schakrava schakrava closed this in c11bc9d Jun 20, 2017

schakrava added a commit that referenced this issue Jun 20, 2017

Merge pull request #1735 from schakrava/614_afp_size_update
update AFP config when share size changes. Fixes #614
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment