| To: | xfs-oss <xfs@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 15/19] mkfs: don't treat files as though they are block devices |
| From: | Jan Tulak <jtulak@xxxxxxxxxx> |
| Date: | Thu, 21 Apr 2016 14:43:21 +0200 |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <1461231593-31294-16-git-send-email-jtulak@xxxxxxxxxx> |
| References: | <1461231593-31294-1-git-send-email-jtulak@xxxxxxxxxx> <1461231593-31294-16-git-send-email-jtulak@xxxxxxxxxx> |
From: Dave Chinner <dchinner@xxxxxxxxxx> âSo the shrinking is happening here: 3127 Â Â Â Â/* 3128 Â Â Â Â * If the data area is a file, then grow it out to its final size 3129 Â Â Â Â * so that the reads for the end of the device in the mount code 3130 Â Â Â Â * will succeed. 3131 Â Â Â Â */ 3132 Â Â Â Âif (xi.disfile && ftruncate64(xi.dfd, dblocks * blocksize) < 0) {â ÂBefore the patch, xi.disfile was 0 and so it didn't shrink the file to the size of the new FS. Now, what is the correct solve to this? Tests are written for the old behaviour, but this shrinking seems to be an intentional thing. It seems that the FS works ok even when this truncating is not applied, so I think that I should remove this chunk (or change it to xi.dcreate=1 only), and keep the old behaviour. What do you think about it, guys? Cheers, Jan |
| Previous by Date: | Re: [XFS] Any process to a particular XFS device hung in D state forever., Brian Foster |
|---|---|
| Next by Date: | [PATCH] xfsdump: fix race condition between lseek() and read()/write(), Eryu Guan |
| Previous by Thread: | [PATCH 15/19] mkfs: don't treat files as though they are block devices, Jan Tulak |
| Next by Thread: | Re: [PATCH 15/19] mkfs: don't treat files as though they are block devices, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |