From: B. Alexander on
On Mon, Apr 26, 2010 at 5:34 PM, Boyd Stephen Smith Jr. <
bss(a)iguanasuicide.net> wrote:

> On Monday 26 April 2010 16:05:31 B. Alexander wrote:
> > On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. <
> > bss(a)iguanasuicide.net> wrote:
> > > I'm also a current reiser3 user. I find the ability to shrink the
> > > filesystem
> > > to be something I am not willing to do without.
> >
> > You know, I said the same thing, but then as the kernel and GRUB and the
> > like advanced, I noticed that my reiserfs partitions would have to replay
> > the journal every time I rebooted, even after a clean shutdown. I started
> > calculating how many times I shrunk any of my partitions in the last 8
> > years, and I can only recall twice. And since I have several terabytes
> > around the house, I figure I can migrate data and delete/recreate
> > partitions if I really need to reduce it.
>
> That doesn't seem right. I have been using reiser3 since 2005, and my
> system
> does not require a journal replay if I do a clean shutdown/reboot. A
> forced
> reboot through Alt+SysRq+B does trigger a journal replay (as it should).
>

No, this is a result of sync;sync;shutdown -r now.


> I also have 4+ tebibytes but most of them are allocated to filesystems.
> I've
> had to shrink filesystems dozens of times since 2005, during or after a
> data
> move.
>

I've had to extend on the fly many more times than I have had to reduce.


> I don't use partitions (much), having been using LVM happily for everything
> except /boot.


As am I. In fact, I even recreated a several of the reiser partitions on my
workstation to see if it was something legacy that may have crept into the
works. The next step is to rebuild, but there are a number of dependencies
before I do that (I want to build 64-bit now that it seems ready for prime
time, but I want to get a higher-end multicore chip, etc etc.)


> I'm hoping to be able to move that onto LVM once I move to
> GRUB2 and GPT.
>

You know, /boot on bare drive has never bothered me, especially since I use
encrypted filesystems on everything but VMs. On laptops, I had it set up so
/boot lived on a thumb drive...So I'm cool with it.


> > > I have not read the rest of the thread, but my off-the-cuff
> > > recommendation would be to start migration to btrfs. Now that the
> > > on-disk format has stabilized, I am going to start testing it for
> > > filesystems other than /usr/local, /var, and /home. Assuming I can
> keep
> > > those running well for 6-12
> > > months, I will migrate /usr/local, /var, and then /home, in that order,
> > > with a
> > > 1-3 month gap in between migrations.
> >
> > I might play with it for some non-critical partitions, or ones that I can
> > mirror on an established filesystem, even if it is only to use in an
> > "Archive Island" scenario, where I have a LV that I can mount, sync and
> > umount. However, btrfs is not included in the kernel, is it? As I recall,
> > nilfs2 has kernel support, but that was the only one of the new
> > filesystems, at the time when I started looking at this.
>
> btrfs is included in 2.6.31.12-0.2-default in openSUSE 11.2. It is also
> included in linux-image-2.6-686 and linux-image-2.6-amd64 for
> lenny-backports,
> testing, and sid. I don't normally deal with other
> architectures/distributions, so it might also be available there.
>


It's not going to live anywhere that I am going to be experimenting on it
other than 686 or amd64 (e.g. my firewall (SPARC), my N810 (ARM) or my WAP
(MIPS)).

>
> > > I've already encountered an issue related to btrfs in my very isolated
> > > deployments. The initramfs created by update-initramfs does not appear
> > > to mount it properly. Instead I am given an '(initramfs)' prompt and I
> > > have to
> > > mount the filesystem manually (a simple two-argument mount command
> > > suffices)
> > > and continue the boot process. This is fine for my laptop, but servers
> > > (and
> > > even my desktop) need to be able to boot unattended; I am still
> > > investigating
> > > the issue, which may just be due to my configuration.
> >
> > That is enough to give me pause...
>
> It doesn't appear to be a file system issue, but rather a problem with the
> initramfs scripts. It could also be rooted in my configuration. I know
> that
> my "root=" kernel parameter has to differ from the device name in my
> /etc/fstab in order to get the initramfs to correctly initialize LVM.
>
> I don't mind being a first adopter for this in particular; I hope to be
> able
> to report good things about btrfs by this time next year.
> --
> Boyd Stephen Smith Jr. ,= ,-_-. =.
> bss(a)iguanasuicide.net ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
> http://iguanasuicide.net/ \_/
>
From: Boyd Stephen Smith Jr. on
On Monday 26 April 2010 16:48:09 B. Alexander wrote:
> On Mon, Apr 26, 2010 at 5:34 PM, Boyd Stephen Smith Jr. <
> bss(a)iguanasuicide.net> wrote:
> > On Monday 26 April 2010 16:05:31 B. Alexander wrote:
> > > On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. <
> > > bss(a)iguanasuicide.net> wrote:
> > > > I'm also a current reiser3 user. I find the ability to shrink the
> > > > filesystem
> > > > to be something I am not willing to do without.
> > >
> > > You know, I said the same thing, but then as the kernel and GRUB and
> > > the like advanced, I noticed that my reiserfs partitions would have to
> > > replay the journal every time I rebooted, even after a clean shutdown.
> >
> > That doesn't seem right. I have been using reiser3 since 2005, and my
> > system
> > does not require a journal replay if I do a clean shutdown/reboot. A
> > forced
> > reboot through Alt+SysRq+B does trigger a journal replay (as it should).
>
> No, this is a result of sync;sync;shutdown -r now.

Well, WFM.

Do you have a log of the shutdown messages that appear on the console? They
might tell us why your filesystem is not getting cleanly re-mounted read-only.

> > I also have 4+ tebibytes but most of them are allocated to filesystems.
> > I've
> > had to shrink filesystems dozens of times since 2005, during or after a
> > data
> > move.
>
> I've had to extend on the fly many more times than I have had to reduce.

Yes. Many, many more times. A filesystem that can't grow is beyond useless
for me. Luckily btrfs support growing and shrinking and it can do both while
mounted. On-line shrinking is a trick I couldn't get reiser3 to perform.

> > I'm hoping to be able to move that onto LVM once I move to
> > GRUB2 and GPT.
>
> You know, /boot on bare drive has never bothered me, especially since I use
> encrypted filesystems on everything but VMs. On laptops, I had it set up so
> /boot lived on a thumb drive...So I'm cool with it.

Well, I will still have to have a "partition" for GRUB to embed stage 1.5 if I
go with GPT. However, it won't contain files per se. I like having as much
as possible on LVM because it makes it easier to migrate to new storage media
and retire the old media.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss(a)iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
From: Rob Owens on
On Mon, Apr 26, 2010 at 01:56:21PM +0200, Javier Barroso wrote:
> On Mon, Apr 26, 2010 at 11:53 AM, Stan Hoeppner <stan(a)hardwarefreak.com> wrote:
> > Mark Allums put forth on 4/26/2010 3:22 AM:
> >> On 4/26/2010 2:14 AM, Stan Hoeppner wrote:
> >>> Mark Allums put forth on 4/25/2010 1:19 AM:
> >>
> >> Sorry Stan, �Your defense of XFS has put me into troll mode. �It's a
> >> reflex. �I don't buy it, but I shouldn't troll.
> >>
> >> I think you are confusing what is with what should be.
> >
> > A'ight, you forced me to pull out the big gun. �Choke on it. �The master
> > penguin himself, kernel.org, has run on XFS since 2008. �Sorry for the body
> > slam. �Is your back ok Mark? ;) �Pretty sure I just "won" this discussion.
> > Err, actually, XFS wins. ;) �BTW, the main Debian mirror in the U.S. is
> > actually housed in kernel.org last I checked. �Thus, the files on your
> > system were very likely originally served from XFS.
> >
> > �The Linux Kernel Archives
> >
> > "A bit more than a year ago (as of October 2008) kernel.org, in an ever
> > increasing need to squeeze more performance out of it's machines, made the
> > leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS.
> > We site a number of reasons including fscking 5.5T of disk is long and
> > painful, we were hitting various cache issues, and we were seeking better
> > performance out of our file system."
> >
> > "After initial tests looked positive we made the jump, and have been quite
> > happy with the results. With an instant increase in performance and
> > throughput, as well as the worst xfs_check we've ever seen taking 10
> > minutes, we were quite happy. Subsequently we've moved all primary mirroring
> > file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With
> > an average constant movement of about 400mbps around the world, and with
> > peaks into the 3.1gbps range serving thousands of users simultaneously it's
> > been a file system that has taken the brunt we can throw at it and held up
> > spectacularly."
> >
> > http://www.xfs.org/index.php/XFS_Companies#The_Linux_Kernel_Archives
> Hello Stan,
>
> Why Debian Installer doesn't change its default filesystem to xfs if
> it is better than ext3 / ext4? I think always is better stick to
> defaults if it is possible
>
I've read articles which state that ext3 has superior resilience to
sudden power loss. That sentiment has been echoed in this thread, by
Stan I think, with statements like (paraphrasing): XFS is good for
production servers which have uninterruptible power supplies.

The resilience is due to the way the journal is written, if I
understand correctly. Maybe somebody on this list who understands it
better can confirm or deny. There is a journal_data_writeback option
for ext3 which will speed up writes to the filesystem, but reduce its
resilience to power loss. With this option enabled, I recall reading
that the ext3 benchmarks are pretty similar to XFS.

I'm not an expert, so don't take my word for it. Do some research on it
yourself, or wait for the real experts to chime in and correct me :)

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100429012405.GA8530(a)aurora.owens.net
From: Rob Owens on
On Mon, Apr 26, 2010 at 08:28:37AM -0500, Stan Hoeppner wrote:
> Javier Barroso put forth on 4/26/2010 6:56 AM:
>
> > Hello Stan,
> >
> > Why Debian Installer doesn't change its default filesystem to xfs if
> > it is better than ext3 / ext4? I think always is better stick to
> > defaults if it is possible
> >
> > Thanks for your explications !
>
> If one disk filesystem was better than all the others in all ways, then
> Linus would only allow one FS in the kernel tree. As of 2.6.33 there are no
> less than 7 stable primary disk filesystems offered in the kernel. Your
> question is a bit simplistic, and not really valid. There is no single
> "perfect" filesystem. IMO, for servers anyway, XFS is pretty close.
>
> Newbies _should_ always stick to defaults. Experts install with expert
> mode, and choose exactly what they want/need.
>
> I didn't write the Debian installer so I can't tell you why EXT is the
> default. I can only speculate. Thankfully the installer offers us expert
> mode so we can do whatever we want. In this regard, I guess the Debian team
> considers EXT the best choice for non-experts.
>
If I'm right that EXT3 has superior resilience to power loss (see my
othe post in this thread) , then that
fact alone makes it a good choice for default filesystem. Many/most
users don't run a UPS and sudden unexpected power loss is a real
possibility for them.

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100429012646.GB8530(a)aurora.owens.net
From: Javier Barroso on
On Thu, Apr 29, 2010 at 3:24 AM, Rob Owens <rowens(a)ptd.net> wrote:
> On Mon, Apr 26, 2010 at 01:56:21PM +0200, Javier Barroso wrote:
>> Hello Stan,
>>
>> Why Debian Installer doesn't change its default filesystem to xfs if
>> it is better than ext3 / ext4? I think always is better stick to
>> defaults if it is possible
>>
> I've read articles which state that ext3 has superior resilience to
> sudden power loss.  That sentiment has been echoed in this thread, by
> Stan I think, with statements like (paraphrasing):  XFS is good for
> production servers which have uninterruptible power supplies.
Good to know, thanks

I will take a look!


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/i2x81c921f31004282356xf4c875bcpf88220aa45102a49(a)mail.gmail.com