Subject: [nfsv4] Space reservation and truncation

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 17 Oct 2012 20:31:01 +0000

>From the design review notes in Vancouver:

> Space Reservations
> 
>   Space Reservations are represented as a attribute of the file.
>   This attribute applies to to the lifetime of the file or until the attribute is "removed".
>   Space reservation occurs upon:
> 	Size and reservation can not be combined in the same operation 
> 	     but can be combined in the same COMPOUND
>   	WRITE
> 	SETATTR of size, greater than the current size
> 	If the file has a size of N, and the space-reservation attribute is attempted to be turned on:
> 	   either the space is reserved to N
> 	   or an error, ENOSPC, is returned and the attribute is not set
>   Lifetime of the reservation is the combination of the file lifetime and the space-reservation attribute
>   ENOTSUP must also be returned if the attribute is not returned
> 
> 
> 
>   Reserve is from 0 to specified size-of-the-file
>   Reservations can not be made beyond the end of the file
>   Truncation of the file (reducing its size), releases the data and the reservation
>   If a reservation is needed beyond end of file a new reservation is needed.
> 
>   - truncate releases the reservation
>   - how does fallocate work on the client and is it related: "NO"
>   - what happens if you write beyond your reserved space?
>     Normal behavior: can receive ENOSPC
>     If you write within the size (as in file length) of the reservation, you are guaranteed space
>     If it is beyond the size, then normal behavior and the space reservation 
>     is increased to the size of the file.
>   - Scenario: set "space-reservation" then set size "up" and reservation is done;
>     if the reservation can not be met, then the set size fails
> 
>   If the data is to be release (sub-range of the file), but the reservation kept, 
>   use INITIALIZE operation

Why does truncation release the reservation?

If we increase the file's size, we increase the reservation.

If we decrease the file's size, we decrease the reservation.

If we hole punch, we keep the reservation.

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 18 Oct 2012 09:31:58 -0400

> Why does truncation release the reservation?

It depends on what "release the reservation" means 

> If we increase the file's size, we increase the reservation.

Yes.

> If we decrease the file's size, we decrease the reservation.

Aka, "release that portion of the reservation covered by the portion of the 
file eliminated by the file size decrease".  Is that what was intended by 
"release the reservation"?

If we SETATTR file size to the current file size value, it should be a no-op.

Suppose a file is 1MB long.

You set the reservation attribute.

Now you write resulting in size being set to 3MB.

Now you truncate to 2MB and you should still have 1MB reserved, which is
clearly true in the "decrease" formulation, but is ambiguous in the "remove'
formulation.

> If we hole punch, we keep the reservation.

Yes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Wednesday, October 17, 2012 4:31 PM
To: nfsv4 list
Subject: [nfsv4] Space reservation and truncation

If we hole punch, we keep the reservation.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 18 Oct 2012 13:37:10 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Noveck, David
> Sent: Thursday, October 18, 2012 9:32 AM
> To: Haynes, Tom; nfsv4 list
> Subject: Re: [nfsv4] Space reservation and truncation
> 

...but what if you have 2 copies of the same file, and a dedup algorithm? :-)

Do you then need to reserve 3MB (2x1MB of "empty" space and 1MB of deduped data)?

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 18 Oct 2012 11:45:07 -0400

> Do you then need to reserve 3MB (2x1MB of "empty" space and 1MB of deduped data)?

As I understand the intention of the spec, the answer is "Yes".  One you turn on
reservation you can rewrite to your heart's content and be assured that you won't get
ENOSPC, even if you do your best to defeat any existing dedup, compression, etc. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Thursday, October 18, 2012 9:37 AM
To: Noveck, David; Haynes, Tom; nfsv4 list
Subject: Re: [nfsv4] Space reservation and truncation

> Of Haynes, Tom

---

From: "Shankararao, Manjunath" <[email-masked]>
Date: Thu, 18 Oct 2012 17:26:57 +0000

>>..

Shouldn't this be "truncation releases the reservation to the extent of the difference between the old size and the new size"

Regards,
/Rudra

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 18 Oct 2012 17:33:54 +0000

On 10/18/12 12:26 PM, "Shankararao, Manjunath"
<[email-masked]> wrote:

>Shouldn't this be "truncation releases the reservation to the extent of
>the difference between the old size and the new size"

Rudra,

Thanks for wording it this way - I think this is one of the issues we had
in discussing the issue in Vancouver.

A space reservation is composed of two attributes of the file:
space_reserved and size.

space_reserved is binary and just indicates that space reservation is
turned on for the file.

If it is set, then the "reservation" is equal to the size of the file.

If we change the size of the file, we change the amount of the
"reservation".

If we hole punch, we are not changing the size attribute, while we may
release blocks.

Let me try to make that clearer in the text.

Thanks,
Tom