hooanon05@xxxxxxxxxxx wrote: > > A. > $ truncate backend_file > $ losetup follow_the_size loopdev > > B. > $ losetup --grow size loopdev backend Are you always going to increase the size? LOOP_SET_CAPACITY suggests you might be better to use a more general --set-capacity option? > I prefer B. > I thought you prefer B too by your mail in last November. > There is one more option which is totally a new utility named logrow > (the TestApp). > Anyway the choice is yours. > > And I've pulled the latest coreutils. > Reading truncate utility, I found it doesn't allocate disk blocks, just > calling ftruncate(). That is a major difference. There is a patch in the works to give `truncate` an --allocate option which will then in turn call posix_fallocate(). This has the advantage of not writing all the blocks if the filesystem supports fallocate(), but will also allow you to shrink the size. If we were to use the external truncate then you could: # grow to 100MB truncate --allocate -s100MB file && losetup --set-capacity 100MB /dev/loopX file # shrink to 100MB losetup --set-capacity 100MB /dev/loopX file && truncate -s100MB file That strikes me as a little awkward but also I'm not sure that losetup should be messing around with the file size at all, especially considering the offset parameter (I didn't notice handling of this in the patch). cheers, Pádraig. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
