[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51731897.vGpjiNuy9t@merkaba>
Date: Tue, 24 Nov 2015 09:48:22 +0100
From: Martin Steigerwald <martin@...htvoll.de>
To: Christoph Hellwig <hch@...radead.org>, linux-btrfs@...r.kernel.org
Cc: David Howells <dhowells@...hat.com>, arnd@...db.de,
linux-afs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [RFC][PATCH 00/12] Enhanced file stat system call
Am Dienstag, 24. November 2015, 00:13:08 CET schrieb Christoph Hellwig:
> On Fri, Nov 20, 2015 at 05:19:31PM +0100, Martin Steigerwald wrote:
> > I know its mostly relevant for just for FAT32, but on any account rather
> > than trying to write 4 GiB and then file, it would be good to at some
> > time get a dialog at the beginning of the copy.
>
> pathconf/fpathconf is supposed to handle that. It's not super pretty
> but part of Posix. Linus hates it, but it might be time to give it
> another try.
It might be interesting for BTRFS as well, to be able to ask what amount of
free space there currently is *at* a given path. Cause with BTRFS and
Subvolumes this may differ between different paths. Even tough its not
implemented yet, it may be possible in the future to have one subvolume with
RAID 1 profile and one with RAID 0 profile.
That said an application wanting to make sure it can write a certain amount of
data can use fallocate. And thats thats the only reliable way to ensure it, I
know of. Which can become tedious for several files, but there is no principal
problem with preallocating all files if their sizes are known. Even rsync or
desktop environments could work like that. First fallocate everything, then,
only if that succeeds, start actually copying data. Disadvantage: On aborted
copies you have all files with their correct sizes and no easy indicates on
where the copy stopped.
Thanks,
--
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists