tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [HEADS-UP] growfs port for ffs2 and ffs1
On Oct,Friday 29 2010, at 11:54 AM, Antti Kantee wrote:
> On Fri Oct 29 2010 at 07:47:08 +0200, Adam Hamsik wrote:
>>>> Existence of resize_ffs which was never included to build and can't resize
>>>> ffs2 file system can't be considered as issue.
>>>
>>> I don't think it's correct to simply declare that others' objections
>>> "can't be considered as issue". Resize_ffs is in our tree, it works, and it
>>> can shrink filesystems, which the code you propose to commit cannot! I
>>> do not think something that duplicates most of its functionality, adds one
>>> new feature (support for ffs2) but omits another (shrinking filesystems)
>>> should be committed.
>>
>> about what we are talking about 2 thousand lines? growfs works for users,
>> resize_ffs doesn't even build by default. How users are supposed to use it
>> ?? In your logic if user want's to grow lvm file system he should download
>> sources, make mechnical chnages to make it work with ffs2, build resize_ffs
>> and resize it.
>
> Adam,
>
> Is there any particular reason you chose to work on growfs instead
> of resize_ffs? The TODO list for resize_ffs seems to consist mostly
> of trivial tasks (including "put it into release lists/etc. and
> src/sbin/Makefile"). The only bigger one is UFS2 support, which naiively
> guessing is a lot less work than adding shrinking to growfs.
Main reason is that growfs is used in production for several years while
resize_ffs used only when needed. I have mase one simple patch to resize_ffs
which will make it more user friendly. With my patch resize_ffs will get device
size automatically and there is no need to use number of DEV_BSIZE blocks as
argument.
>
Regards
Adam.
Home |
Main Index |
Thread Index |
Old Index