Re: 2TB USB hard drive for backing up
On Sun, 29 Apr 2012 20:16:58 +0200, Martin Steigerwald wrote:
> Am Dienstag, 24. April 2012 schrieb Camaleón:
(...)
>> As an aside note, I've been using ReiserFS in all of my linux boxes (in
>> both, servers and workstations) for the "/" partition and I never had
>> to face the long waits at booting till the fsck ends. I know that
>> ReiserFS (v3) is not actively developed (just security patches) and
>> performs better for small files but I'm considering in moving ext3 to
>> XFS or another mature file system (JFS) because the annoying and
>> absurdly long time fsck takes.
>
> Reiserfs has some more drawbacks:
>
> - long mount times on large volumes
>
> - doesn´t distinguish between different filesystems on fsck like
> - loopback file with reiserfs on reiserfs
> - vm image file with reiserfs on reiserfs
>
> Especially the latter is a no-go for me, cause an fsck would mix up the
> several reiserfs filesstems.
I haven't had experienced any of that issues in any of my systems so I
still find ReaiserFS the most suitable filesystem for me.
The only big drawback I see for ReiserFS v3 is that it does not receive
more enhancements nor features just patches, which can leave your
installation in a very delicated state if something goes wrong. OTOH, I
don't know about the current status of ReiserFS v4, I have not heard any
news since many years :-?
> XFS might also have long file check times.
I still have not tried this so I can't really tell but what I've heard on
XFS is not comparable to ext3, I mean, in regards with the time it takes
to perform a filesystem check.
> fsck times depend more on the number of inodes than on the size of the
> filesystem. They also depend on the version of the check tool.
>
> XFS develovers tuned xfs_repair heavily regarding speed and memory
> usage. And I seem to recall some optimizations for Ext4 as well, like
> unitialized block groups (bguninit or something lile that in tunefs -l).
>
> My Ext4 fsck times on large volumes are quite good. A few minutes
> usually. Even on the backup drive which holds at least 1 million inodes
> in one logical volume.
My experience with ext3 and fsck times also varies depending of the
volume file size: my 500 GiB hard disk can delay up to 5 min. but the
server's 1.2 TiB volume do take longer...
>> > Its very convenient to have a large sack to toss the stuff, but it
>> > has its own set of drawbacks :)
>>
>> Yes, and I'm against partitioning too much but considering the big
>> sizes of the actual hard disks it has become a must, also to minimize a
>> filesystem corruption in a partition that can affect the whole data.
>
> I use LVM quite a lot, but I am a bit annoyed by having to vgchange -ay
> after inserting and vgchange -an before removal. I like to see a
> removable flag for LVs that lessens the locking restrictions that are
> important in certain enterprise setups, so that I can have an LVM be
> scanned automatically and do not need to run vgchange.
I wish hard disk partitioning becomes more handly and flexible and it
gets implemented on the filesystem "natively" without having to deal with
external tools, such as LVM.
Greetings,
--
Camaleón
Reply to: