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 



Home | Main Index | Thread Index | Old Index